OpenGL und die Fixed-Function-Pipeline

Transkript

1 OpenGL und die Fixed-Function-Pipeline Proseminar Game Design WS 07/08 Jan-Hendrik Behrmann Einführung In modernen Computerspielen hat sich inzwischen die Darstellung der Spielwelt in dreidimensionaler Grafik durchgesetzt. Dabei zeigt der Trend noch immer in Richtung einer immer realistischeren Abbildung der Wirklichkeit, gleichzeitig soll die Grafik möglichst flüssig laufen. Die dazu notwendigen Berechnungen werden von spezialisierter Hardware übernommen, die heute auf der Grafikkarte in nahezu jedem PC verbaut ist. Um diese Hardware nutzbar zu machen bedarf es einer Software-Schnittstelle, die der Spieleprogrammierer nutzen kann. In den letzten Jahren haben sich zwei dieser Schnittstellen durchgesetzt: DirectX und OpenGL. Im Folgenden soll es um OpenGL und die darunterliegende Rendering-Pipeline gehen. OpenGL Die Open Graphics Library (kurz OpenGL) ist eine Spezifikation einer Programmierschnittstelle (API) zur Programmierung von 3D-Grafik-Anwendungen. Sie wurde von Silicon Graphics Inc. (heute SGI) im Jahr 1992 entwickelt und veröffentlicht. Die OpenGL zeichnet sich dadurch aus, dass sie nicht an bestimmte Hardware oder an ein bestimmtes Betriebssystem gebunden ist. Sie ist als Low-Level-API konzipiert, bietet dem Programmierer also nur sehr grundlegende, nahe an die Hardware angelehnte Funktionen. Die Spezifikation sieht vor, dass eine Implementierung der API alle in der Spezifikation vorgesehenen Funktionen implementieren muss und diese, wenn sie nicht von der Hardware unterstützt werden, notfalls in Software emulieren muss. Der Programmierer kann sich also auf einen verbindlichen Leistungsumfang verlassen, freilich zu dem Preis, dass es passieren kann, dass seine Anwendung sehr langsam läuft, weil ein genutztes Feature auf einer Hardware nicht unterstützt wird und emuliert werden muss. Da die technische Entwicklung im Bereich der 3D-Grafik sehr rasch voranschreitet, muss die Library ständig erweitert und gepflegt werden. Diese Aufgabe hat das Architecture Review Board (ARB) übernommen, ein Industriekonsortium, das 1992 extra zu diesem Zweck gegründet wurde. Mitglied im ARB sind neben SGI weitere einflussreiche Unternehmen der Branche, etwa NVIDIA, AMD/ATI, Intel und weitere. Seit September 2006 ist das ARB eine Untergruppe der Khronos Group, ein Konsortium, das sich der Entwicklung freier Multimediastandards verschrieben hat. Die Fixed-Function-Pipeline Um dreidimensionale Welten auf dem üblicherweise zweidimensionalen Bildschirm wiedergeben zu können (oder in einer Grafikdatei zu speichern), müssen die Daten speziell aufbereitet werden. Die Abfolge der einzelnen Verarbeitungsschritte ist dabei immer dieselbe. Diese Kette von Verarbeitungsschritten bezeichnet man als Rendering-Pipeline. Eine Pipeline bezeichnet dabei eine sequentielle Anordnung von Prozessen, wobei der Output des einen der Input des nächsten Verarbeitungsschrittes ist. Ihre besonderen Vorteile

2 liegen darin, dass sie sich durch ihren festen Ablauf einfach in Hardware implementieren lässt und durch die Anordnung mehrerer Rendering-Pipelines auf der Grafikhardware eine hohe Parallelisierung erreicht werden kann. Damit lässt sich ein hoher Geschwindigkeitsvorteil gegenüber der Berechung auf einer Standard-CPU erreichen. Vor der Version 2.0 benutze OpenGL ausschließlich die sogenannte Fixed-Function-Pipeline. In ihr war die Funktion aller Verarbeitungsschritte fest vorprogrammiert und nur über die Einstellung einiger weniger Parameter zu beeinflussen. Ab der Version 2.0 ist die Pipeline in Teilen über sogenannte Shader-Programme programmierbar. Zur Veranschaulichung des Rendering-Prozesses soll uns die Fixed-Function-Pipeline genügen. Der Rendering-Prozess Die Abbildung zeigt die Rendering-Pipeline in stark vereinfachter Form. Die tatsächliche Pipeline von OpenGL ist viel umfangreicher, würde aber den Rahmen dieser Arbeit sprengen. Zunächst müssen wir wissen, wie OpenGL intern Grafikobjekte beschreibt. Es beschreibt sie als eine Liste von Vertices, die zusammen einen Primitiv ergeben. Per-Vertex Operations Diese Übersicht zeigt die von OpenGL unterstützten Primitive, darunter als Einfachstes eine Punktmenge, Linien, aber auch komplexe Objekte wie Polygone. Am Beispiel des Dreiecks erkennen wir, dass die Vertices die Eckpunkte der Primitive beschreiben. Sie speichern neben den Raumkoordinaten aber auch Farbwerte, Texturkoordinaten und andere Informationen. OpenGL schickt dabei jeden übergebenen Primitiv unverzüglich einzeln durch die Pipeline. Im ersten Verarbeitungsschritt werden alle übergebenen Vertices einzeln wie folgt verarbeitet: Sie werden im dreidimensionalen Raum platziert (Model Transformation). Ihre Koordinaten werden in Kamerakoordinaten umgerechnet (Viewing Transformation). Es werden Beleuchtungsinformationen für jeden Vertex erstellt (Lighting). Sie werden auf zweidimensionale Koordinaten projiziert (Projection Transformation).

3 All diese Schritte werden durch Multiplizierung der Koordinaten, die man als Vektoren auffasst, mit speziellen Matrizen realisiert. Model Transformation Häufig benutzt man bereits vorgefertigte 3D-Modelle für seine Szene. Diese liegen aber nur in ihrem lokalen Koordinatensystem vor. Darum müssen diese Koordinaten in das Weltkoordinatensystem der Szene überführt werden (s. Abbildung). OpenGL bietet dazu vorgefertigte Transformationsmatrizen für das Verschieben, Skalieren und Drehen eines Objekts. Viewing Transformation Als nächster Schritt erfolgt die Viewing Transformation. Dabei werden alle Weltkoordinaten in Kamerakoordinaten umgerechnet. Das ist deswegen erforderlich, weil die Kamera zwar frei im Raum positioniert werden kann, es aus mathematischer Sicht aber wünschenswert ist, wenn sich die Kamera im Ursprung des Koordinatensystems befindet und die Tiefenachse hinunterblickt (OpenGL nutzt ein rechtshändiges Koordinatensystem). Die dazu notwendige Matrix wird über eine spezielle Funktion erzeugt. Lighting An dieser Stelle werden nun für jeden Vertex abhängig von den Lichtquellen im Raum Beleuchtungsinformationen nach dem Phong-Modell berechnet. Für eine genauere Beschreibung sei auf den Vortrag zu diesem Thema verwiesen. Projection Transformation Nun müssen die Vertices auf die zweidimensionale Ebene projiziert werden. Dazu gibt es zwei Verfahren: Die orthogonale und die perspektivische Projektion. Die perspektivische Projektion ist dem menschlichen Auge ähnlich. Das Sichtfeld des Auges kann als Kegel angesehen werden, der seine Spitze am Auge hat und von dort aus immer breiter wird. Bei OpenGL ist es ähnlich, nur bedient man sich hier eines Pyramidenstumpfes, des sogenannten Frustums.

4 Das Sichtfeld der Kamera wird also als eine Pyramide aufgefasst. Zum Stumpf wird sie dadurch, dass man die Pyramide an der Near Clip Plane und Far Clip Plane abschneidet. Alles was sich vor der Near Clip Plane, hinter der Far Clip Plane oder außerhalb der Pyramide befindet ist nicht sichtbar, das Frustum beschreibt also den gesamten sichtbaren Bereich. Der zweite Teil der Projection Transformation besteht darin, dass alle Koordinaten so transformiert werden, dass das Frustum innerhalb eines Einheitswürfels zwischen den Koordinaten (-1, -1) und (1, 1) liegt. Bei der Transformation eines Pyramidenstumpfes zu einem Würfel treten Verzerrungen auf: Nahe Objekte erscheinen größer, während entfernte Objekte kleiner wirken, Winkel verändern sich. Dieser Effekt ist gewollt, entspricht er doch dem menschlichen Seheindruck. Die orthogonale Projektion verläuft analog, nur wird hier das Sichtfeld nicht als Pyramidenstumpf sondern als Quader aufgefasst. Dadurch treten bei der Transformation keine Verzerrungen auf, Größenverhältnisse bleiben erhalten. Diese Art der Projektion ist den meisten aus 3D-Editoren bekannt, wo sie beim Erstellen von Modellen verwendet wird. Primitive Assembly Die Per-Vertex Operations sind damit abgeschlossen. Auf dieser Stufe werden Primitive als Ganzes behandelt. Dabei ist es das Hauptziel, so viele unsichtbare Primitive wie möglich zu entfernen, um Rechenzeit zu sparen. Zunächst werden Primitive, die uns ihre Rückseite zuwenden, entfernt. Sie gelten als nicht sichtbar. Diesen Schritt bezeichnet man als Backface Culling. Als nächstes werden alle Primitive, die nicht innerhalb des sichtbaren Bereiches liegen, entfernt. Durch die Projektion auf den Einheitswürfel ist dies sehr leicht. Primitive, die nur zum Teil innerhalb des sichtbaren Bereichs liegen, werden an den Würfelkanten abgeschnitten. OpenGL fügt selbstständig neue Vertices ein, wenn dies nötig ist. Diesen Schritt bezeichnet man als Clipping. Viewport Transformation Bis zu diesem Moment geschah noch alles im dreidimensionalen Raum, hier werden die Koordinaten endgültig in den zweidimensionalen Raum projiziert, indem man die Tiefenkoordinate einfach entfernt. Verloren ist die Tiefeninformation dennoch nicht, sie wird gespeichert und später noch gebraucht. Anschließend werden die Koordinaten aus dem Einheitssystem ein letztes Mal in ein Koordinatensystem transformiert, das die Ausmaße des Anzeigebereichs auf dem Bildschirm (Viewport) hat.

5 Rasterization Bei der Rasterization werden nun die immer noch in Form von Koordinaten vorliegenden Primitive auf ein Raster übertragen. Der dabei zur Anwendung kommende Algorithmus ist das Scanline Rasterizing. Dabei überprüft der Algorithmus zeilenweise an jedem Bildpunkt, ob dieser vom Primitiv überdeckt wird. Ist dies der Fall, so berechnet der Rasterizer durch Interpolation aus den Farb- und Lichtinformationen der benachbarten Vertices die Farbe, die dieser Bildpunkt erhalten soll. Tragen die Vertices Texturkoordinaten, so wird auch aus ihnen durch Interpolation eine Texturkoordinate für diesen Bildpunkt berechnet. Aus der Textur selbst wird an dieser Stelle allerdings noch nicht gelesen. Ebenso wird aus den Tiefenwerten der Vertices ein Tiefenwert interpoliert. Mit den so berechneten Daten erstellt der Rasterizer für jeden Bildpunkt ein sogenanntes Fragment. Per-Fragment Operations Diese Fragments müssen im letzten Schritt noch einmal einzeln verarbeitet werden. Zunächst wird bei allen Fragments, die im vorherigen Schritt eine Texturkoordinate zugewiesen bekommen haben, der Farbwert an der passenden Stelle der Textur gesucht und dem Fragment zugeordnet. Anschließend wird durch optional aktivierbare Tests überprüft, ob das Fragment dargestellt werden soll. Ein solcher Test ist zum Beispiel der Tiefentest. Dabei wird die Tiefeninformation des Fragments mit dem Depth Buffer, einer Datenstruktur, die über mehrere Durchläufe der Rendering-Pipeline die Tiefenwerte jedes gezeichneten Bildpunktes speichert, verglichen. Wurde an dieser Stelle bereits ein Bildpunkt an geringerer Bildtiefe ( davor ) gespeichert, so wird das Fragment verworfen. Ist dies nicht der Fall und das Fragment besteht auch eventuelle andere Tests, so wird sein Farbwert schließlich in den Framebuffer geschrieben bzw. mit einem bereits bestehenden Farbwert vermischt. Ausblick Wie bereits erwähnt, gilt die Fixed-Function-Pipeline aufgrund ihrer begrenzten Möglichkeiten inzwischen als überholt. Der Trend geht eindeutig zu programmierbaren Grafikchips und OpenGL in seiner aktuellen Version 2.1 unterstützt in Teilen bereits eine programmierbare Pipeline. Die nächste OpenGL Version 3.0 soll diesem Trend folgen können. Die Fixed-Function- Pipeline wurde komplett entfernt und es wurden größere Umbauarbeiten an der API vorgenommen. Allerdings geht dieser Fortschritt zu Lasten der Abwärtskompatibilität, die bei 3.0 erstmals nicht gegeben sein soll. OpenGL 3.0 ist angekündigt für Anfang 2008, bisher jedoch nicht erschienen.

6 Weiterführende Literatur Dave Shreiner, Mason Woo, Jackie Neider: OpenGL Programming Guide (6. Auflage). Addison-Wesley Longman, 2007 Links (Offizielle OpenGL-Homepage) (Homepage der Khronos Group)