Tutorial OpenGL3

Vorwort

Willkommen zur Einführung in OpenGL3.x. Im Rahmen, dieses Artikels, werde ich versuchen die Grundlagen für die nutzung von OpenGL3 zu legen und durch Pseudo Code die Verwendung von der API aufzeigen. Mit OpenGL Version 3 hat sich vieles, im vergleich zu den Vorversionen, verändert und entsprechend ist der Umstieg von OpenGL1-2 auf 3 sehr Zeitaufwändig. Dieser Artikel richtet sich mehr an Anfänger als an Programmierer, die von der Vorversion umsteigen wollen.

Grundlagen

OpenGL3 und die Vorgeschichte

OpenGL ist viele Jahre alt und entsprechend gab es immer wieder neue Versionen und Änderungen. Doch entfernte sich OpenGL mit der Zeit vom aktuellen Stand der Technik und veralterte immer mehr. Die API wurde größer und größer, alte nicht mehr gebrauchte Funktionen wurden aus Kompatibilitätsgründen nicht entfernt und die Treiber wuchsen zu riesigen und komplexen Codewerken. Darunter hat entsprechend die Leistung und Qualität stark gelitten. Es musste ein radikaler Schnitt gemacht werden und man beschloss dies mit OpenGL Version 3 zu tun. So hat man sämtlichen balast von früher raus gestrichen und eine Hand voll neuer Funktionen hinzugefügt.

Um die Umstellung für Software leichter zu machen, beschloss man 2 verschiedene Profiele zu unterstützen. Das erste Profiel ist ein OpenGL3 fähiger Grafik Context, welcher auch die alten Befehle ausführen kann und somit die Umstellung Schrittweise ermöglicht. Das zweite Profiel ist ein OpenGL3 fähiger Grafik Context, welcher nur die als nicht veraltet(deprecated) makierten Funktionen ausführen kann und für neue Software gedacht ist. Sollte man mit dem 2. Profiel arbeiten und ruft dennoch eine alte Funktion auf, dann wirft diese ein Fehler und wird nicht ausgeführt.

Mit den neuen Fähigkeiten der Grafikkarten entstanden parallel zu den OpenGL Versionen auch neue Shader Update. OpenGL verwendet Shader, um die Darstellung von 3D Modelle manipulieren zu können. So hat man anfangs mit Assembler ähnlichen Code und später mit C ähnlichen Code mini Programme geschrieben, welche auf dem Grafikprozessor lauffähig waren. Man hatte zwischen Vertice- und Fragment-Shadern/Programmen unterschieden. Mit dem Shader Modell 4 kam eine weitere Shader Kategorie hinzu, unzwar Geometrie Shader. Wärend Vertice-Shader einzelne Punkte eines Drahtgitters manipulieren konnte, hat der Fragment-Shader das ausfüllen des Drahtgitters übernommen(shading) und die Geometrie-Shader erlauben die manipulation des Drahtgitters. Wärend Shader in OpenGL1-2 nicht notwendig waren, kann man in OpenGL3 nicht ohne auskommen, da ein Vertex-/Fragment-Shader zum zeichnen benötigt wird.

Ein sehr beliebtes Werkzeug, in OpenGL1-2, war der immidate mode, welcher das einfache zeichnen von 3D Daten erlaubte. Dieser wurde durch ein glBegin eingeleitet, ein glEnd beendet und alles was dazwischen stand wurde gezeichnet. Dies hatte allerdings auch seinen Preis, so war der Treibercode dadurch enorm komplexer geworden und es mussten aufgrund der vielen möglichen Variationen(gesetzte Flags) viele Prüfungen durchgeführt werden, um einen gültigen Rendercode zu erzeugen. Dieser wurde ebenfalls in OpenGL3 gestrichen und man muss nun sogenannte Vertex Buffer Objects oder Buffer Objects verwenden. Diese haben den Vorteil, dass sie wesentlich schneller und recht einfach zu bedienen sind.

In OpenGL1-2 war es möglich die Modelview und Projectionview Matrizen durch bestimmte API Befehle zu manipulieren. Die Modelview Matrix hat die Position eines Objektes so manipuliert, dass es den gewollten Platz in der 3D Welt eingenommen hat und die Projectionview Matrix hat dann die 3D Weltkoordinaten auf 2D Bildschrimkoordinaten transformiert. Mit OpenGL3 sind ist diese Möglichkeit entfernt worden, da nun der Vertexshader diese Arbeit übernommen hat und diese Funktionalität mehr in den Anwendercode als in die Bibliothek gehört.

Die letzten 3 angesprochenden Punkte(Shader,immedate mode und Matrizen) haben großen Einfluss auf den Basis Code einer OpenGL3 Anwendung. Dieser fällt größer und Umfangreicher aus als ein Basis Code für OpenGL1-2 aber wird später kaum größer, aufgrund der Schlankheit der neuen API.

Der Grafik Contex

Der Grafik Contex(GC) ist die Basis von OpenGL, man kann mehrere GCs in einem Prozess haben, was aber selten Sinn macht. Im GC werden alle Notwendigen Informationen gehalten, um mit der GPU zu arbeiten, dabei werden Identifier(ID) verwendet, um Resourcen nach aussen Verfügbar zu machen. Zu solchen Ressourcen gehören z.B. Texturen, Shader, diverse Buffer Objects und alle werden durch IDs zur verfügung gestellt. Neben den ID-Listen werden noch sogenannte States, Informationen für die Bildausgabe und diverse unbekannte Treiberspezifische Daten gespeichert.

Profiel

Um die einzelnen Befehlssätze zu Verwalten hat man sogennante Profiele eingeführt. OpenGL3 ist z.B. ein Profiel, es gibt noch weitere Profiele wie z.B. OpenGL3.1 oder OpenGL3.1 Debug. Die Profiele werden vom ARB fest gelegt und es gibt in der Regel 2 Versionen, mit und ohne deprecated maktierte Funktionen.

Forward compatible context und Full context

Es gibt 2 Varianten eines Context, der Full context ist enthält alle Funktionen, auch die als deprecated maktierten. Der Forward compatible context enthält nur die nicht als deprecated makierten Funktionen des OpenGL Kerns. Bis zur Version 3.1 gab es immer eine abwärts Kompatibilität und der Treiber hatte entschieden, welche OpenGL Version verwendet werden darf. Mit OpenGL 3.1 gibt es keine abwärts Kompatibilität mehr und man kann festlegen, was für ein GC man haben möchte.

Verwaltung der veralteten und neuen Funktionen

Das hinzukommen und das entfernen von OpenGL Funktionen unterliegt dem Deprecation und Extension Mechanismus. Diese funktionieren wie folgt.

Deprecation Path: Core->ARB->Vendor/Extension

Die Funktion wird erst aus den Bereich der Kernfunktionen entfernt und als ARB zur verfügung gestellt. Dann wird sie aus dem ARB entfernt und als Vendor oder Extension weiter geführt. Der Kern wird von der Khronos Group verwaltet, das ARB wird von einer Gruppe bestehend aus AMD/ATI, Nvidia, SGI, Sun, Intel, IBM, Apple, 3DLabs und einigen weiteren zusammen verwaltet und Vendor sowie Extension werden von Firmen wie AMD, Nvidia, SIS und so weiter einzeln verwaltet.

Extension Path: Vendor/Extension->ARB->Core

Wenn eine Extension, von einer Firma, vom ARB als sinnvoll angesehen wird, dann wird diese mit aufgenommen. Funktionen, die vom ARB aufgenommen wurden, werden in der Regel mit der kommenden OpenGL Version in den Kern aufgenommen.

OpenGL3 macht regen gebrauch von diesen Mechanismen, da viele Kernfunktionen als deprecated makiert wurden und nun über die einzelnen Updates aus dem Kern verschwinden. Da sich der Stand der Technik weiter Entwickelt kommen natürlich auch neue Funktionalitäten hinzu, so z.B. Transform Feedback, Instancing oder GLSlang 1.4 .

Verwaltung eines OpenGL3.x GC

Um ein GC ertellen zu können wird eine weitere API benötigt, welche Platformabhänig und durch wgl[Funktionsname]/glX[Funktionsname] erkennbar ist. Mit diesen Befehlen kann man mit den Windows und X11 Desktop Manager zusammen arbeiten. So werden Funktionen für das erstellen, wechseln, zerstören eines GC, laden von Extension, wechseln des Fensterpuffern und Synchronisieren von CPU und GPU ermöglicht. Bisher gibt es noch keine Möglichkeit einen OpenGL3 fähigen GC zu erstellen, ohne dafür eine Funktion vom ARB zu verwenden. Der Nachteil von ARB Funktionen sind, dass man einen gültigen GC benötigt den Zeiger auf diese zu erhalten. Um einen OpenGL 3.0 oder 3.1 GC zu erstellen benötigt man einen OpenGL1-2 GC und die Kernfunktion wglGetProcAddress/glXGetProcAddress. Einen gültigen OpenGL1 bzw. OpenGL2 GC bekommt man über den Befehl wglCreateContext/glXCreateContext und zwischen mehreren GC kann man mit dem Befehl wglMakeCurrent/glXMakeCurrent wechseln. Der Befehl für die Erstellung eines OpenGL3 fähigen GC heisst wglCreateContextAttribsARB/glXCreateContextAttribsARB. Mit OpenGL3.2 soll eine Funktion in den OpenGL Kern kommen, welcher es erlaubt einen OpenGL3 und aufwärts fähigen GC zu erstellen, ohne einen älteren GC vorher zu erstellen.