HomeMapIndexSearchNewsarchivesLinksabout LF
[Top Bar]
[Bottom Bar]
[Photo of the Author]
Miguel Angel Sepulveda

Über den Autor:
Miguel machte seinen Abschluß an der Washingtoner Universität im Jahre 1993. Danach arbeitete er als Wissenschaftler in Spanien, Japan und den USA. Mit Linux traf er das erste Mal zusammen, als der Kernel noch bei Version 0.98 stand, es war Liebe auf den ersten Blick. Gegenwärtig ist er in seiner Freizeit Chefredakteur des LinuxFocus.

M@ail an den Autor

Was ist OpenGL?

[OpenGL logo]


Zusammenfassung:
Mit diesem Artikel startet eine monographische Reihe über OpenGL und seiner Unterstützung unter Linux. Sie richtet sich an Programmierer, die sich die Leistungsfähigkeit von OpenGL im 2D und 3D Grafikbereich für ihre Programme zunutze machen wollen.



OpenGL ist, ohne Zweifel, die im professionellen Bereich vorherrschende API ("Application Programming Interace", Programmier-Bibliothek) für die Entwicklung von 2D und 3D Grafikprogrammen. Sie stellt praktisch den Nachfolger der erstklassigen IRIS GL-Bibliothek von Silicon Graphics dar, die die beliebten SGI Workstations zur bevorzugten Plattform der Programmentwicklung in der Wissenschaft, dem Ingenieurwesen und für Spezialeffekte machte. SGI brachte einen großen Teil ihres Wissens und ihrer Fähigkeiten ein, um aus OpenGL die Grafikbibliothek der Zukunft zu machen, die einfach in der Handhabung, intuitiv, portabel und netzfähig sein sollte. Gleichzeitig verdient SGI großen Dank für die Tatsache, daß die Firma die Wichtigkeit von offenen Standards erkannt hat. Eine Reihe von Hardware- und Softwarehersteller beteiligten sich bei der Spezifizierung von OpenGL und unterstützen sie. Dadurch können OpenGL Programme relativ einfach auf praktisch jede Plattform portiert werden, sei es von einem Windows95 PC nach Linux, auf eine High-End UNIX Workstation oder auch auf einen Mainframe. Das Architectural Review Board überwacht die OpenGL Spezifikationen, akzeptiert oder verwirft Änderungsvorschläge und bietet Tests an, die die Konformität von Programmen überprüfen.

Im Gegensatz zu SGIs alter IRIS GL-Bibliothek ist OpenGL von der Konzeption her unabhängig von Plattform oder Betriebssystem. Es ist netzwerkfähig, wodurch eine OpenGL Anwendung in einen Serverteil und einen Clientteil aufgeteilt werden kann, und so Berechnungen von der letztendlichen Darstellung getrennt werden können. Dazu existiert ein Netzwerkprotokoll, über das OpenGL Kommandos zwischen Server und Client ausgetauscht werden können. Dank der Plattformunabhängigkeit können Server und Client auf verschiedenen Plattformtypen laufen. Nicht selten sitzt der Server auf einem Supercomputer, welcher eine komplexe Simulation betreibt, während der Client auf einer einfachen Workstation zu finden ist, die nur für die grafische Darstellung zuständig ist. OpenGL ermöglicht Entwicklern, Programme zu schreiben, die relativ einfach auf vielen verschiedenen Plattformen eingesetzt werden können.

Vor allem ist OpenGL eine effektive, leistungsfähige Grafikbibliothek, und es gibt viele Grafikkarten mit 2D und 3D Hardwarebeschleunigern,die OpenGL Funktionalitäten auf Hardwareniveau realisieren. Bis vor kurzem waren diese Hochleistungskarten recht teuer und nur für SGI Rechner und andere UNIX Workstations erhältlich. Es ist Silicon Graphics mit ihren großzügigen Lizenbedingungen und ihren Softwarepaketen für die Entwicklung von Anwendungen zuzuschreiben, daß immer mehr OpenGL unterstützende Hardware auch für den PC Bereich verfügbar wird. Und, jawohl, auch Linux-Benutzer kommen in ihren Genuß. 3dfx Interactive, eine Firma, die eine Reihe von 3D Karten für den PC vertreibt, unterstützt Linux durch die Bereitstellung ihrer Glide Bibliothek. In dieser Ausgabe ist ein weiterer Artikel zu diesem Thema zu finden, 3Dfx Graphikkarten von Phillip Ross. Dieser stellt detailliert die erhältlichen 3dfx Karten vor. Offensichtlich ändert sich langsam aber sicher die Einstellung der Hardwarehersteller, die letzlich einzusehen scheinen, daß Linux ein fester Bestandteil der heutigen und zukünftigen Computerwelt ist. Linuxer sollten dies entsprechend würdigen und solche Initiativen unterstützen.

Damit OpenGL hardwareunabhägig sein konnte, wurde sowohl Fensterverwaltung, als auch Benutzereingabe aus der Bibliothek ausgeschlossen. Dies mag sich zuerst nach einem schweren Nachteil von OpenGL anhören, später (siehe Artikelserie über die GLUT Programmierung) wird aber gezeigt, wie OpenGL zusammen mit anderen flexiblen Programmierbibliotheken eingesetzt wird, welche Fensterverwaltung und die Eingabe von Benutzern handhaben. Desweitern bietet OpenGL keine Befehle für das Erzeugen komplexerer Objekte, wie Moleküle, Flugzeuge, Häuser, Vögel usw. Vielmehr werden nur grundlegende geometrische Objekte (Punkte, Linien, Polygone) zur Verfügung gestellt. Es liegt in der Hand des Entwicklers, eigene Modelle aus diesen Basisobjekten zu erzeugen. Es existieren einige OpenGL verwandte Bibliotheken, welche komplexere Objekte unterstützen, es steht jedem Benutzer frei, diese für seine eigenen Modelle zu verwenden.

In dieser Artikelserie über OpenGL Programmierung wird mit der C Schnittstelle gearbeitet, da diese die beliebteste ist. Allerdings sollte dem Leser nicht verschwiegen werden, daß auch andere Sprachen OpenGL nutzen können, wie zum Beispiel FORTRAN, C++, Ada oder Java. Sobald der Leser später mit der C Schnittstelle von OpenGL vertraut ist, wird auch ein wenig auf Open-Inventor, eine C++ Erweiterung der OpenGL Bibliothek, eingegegangen.

Ohne jetzt schon allzu sehr ins Detail zu gehen, werden hier einige der Features vorgestellt, die OpenGL anbietet:

Wie schon erwähnt, war es für die Portabilität und Platttformunabhängigkeit von OpenGL notwendig, alle Kommandos, die etwas mit der Fensterverwaltung zu tun haben, links liegen zu lassen. Dazu zählen: ein Fenster zu öffnen und zu schließen, seine Größe zu verändern, Cursorposition auszulesen, uvm. Selbiges gilt für die Benutzereingabe, zum Beispiel Tastatureingabe,... Alle diese Operationen sind in hohem Grade abhängig vom Betriebssystem. Ursprünglich besaß die GL-Bibliothek ihre eigenen Kommandos für Fenster- und Eingabesteuerung. Diese waren allerdings IRIX spezifisch (das UNIX von Silicon Graphics). Es bleibt dem jeweiligen OpenGL Entwickler überlassen, sein System zu kennen und sich um die Fenstersteuerung selbst zu kümmern.

Dank Mark J. Kilgard von SGI gibt es eine weitere Bibliothek, die dieses Problem lösen soll. Mark schrieb die GLUT-Bibliothek, ein GL Toolkit, welches die alte AUX Bibliothek ersetzt (nicht fragen, was die AUX Bibliothek war, einfach vergessen). GLUT ist frei verfügbar, wie OpenGL gibt es sie sowohl in der Quelltextversion als auch als Binärpaket für Linux. Die Bibliothek ist plattformabhängig und bietet einen allgmeinen Mechanismus für die Fenster- und Eingabesteuerung. Will also ein OpenGL Programm ein Fenster für eine Animation öffnen, so nutzt es den GLUT Befehlssatz, welcher sich um das zugrundelegende Fenstersystem kümmert. GLUT schirmt also den Entwickler von den Details des jeweiligen Fenstersystems (X11, Windoof, Motif,...) ab, so daß sich dieser ganz auf seine eigentlich Aufgabe, die OpenGL Programmierung, konzentrieren kann. Durch GLUT wird der Programmcode plattformunabhängig. Ich selbst habe eine Protein und Gel Simulation geschrieben, die GLUT und OpenGL nutzt. Diese konnte ich problemlos und ohne eine einzige Zeile mit maschienenspezifischen Kode unter Linux x86, Linux Alpha und Windows95 kompilieren und laufen lassen (ja, ich gestehe, daß ich Windows95 von Zeit zu Zeit benutze ;-). Es kann dem an OpenGL interessierten Leser nur geraten werden, sich mit GLUT für die Fensterverwaltung zu beschäftigen.

Gute Kenntnisse über GLUT sind genauso wichtig, wie das Erlernen von OpenGL. Deswegen wird in der OpenGL Serie hier im LinuxFocus ebenfalls eine Reihe von Artikeln erscheinen, welche Schritt für Schritt in den Gebrauch von GLUT einführen und den bequemen Einsatz der Eingabegeräte beschreiben.

Bevor diese kurze Einführung sich ihrem Ende nähert, sollte ein anderer "Master of The Universe" nicht ungenannt bleiben: Brian Paul. Er ist derjenige, der fortlaufend und geduldig eine 3D Bibliothek (auch für Linux) namens Mesa weiterentwickelt. Mesa ist Open-GL ähnlich, das heißt, es ist keine lizensierte OpenGL Implementierung, wird jedoch mittels den Konformität-Tests von SGI geprüft. Momentan unterstützt Mesa selbst nur Software Rendering, d.h. der Prozessor übernimmt alle Berechnungen, die normalerweise an die 3D Hardware weitergereicht werden würden. Jedoch gibt es intern Anknüpfpunkte (Hooks), welche es erlauben, Treiber für Beschleunigerhardware zu entwickeln und einzusetzen. Solche Treiber existieren momentan nur für Mondello, S3 Virge (nur Win95), GLINT und Voodoo 3dfx Chipsätze. Dank der Voodootreiber (von David Bucciarelli) kann Mesa dieselbe Leistung erbringen, wie teure SGI Workstations, wer also an Hochleistungsgrafiken im 3D Bereich interessiert ist, sollte sich eine 3dfx Karte zulegen.

Zum Schluß komme ich nicht darum herum, einige persönliche Erfahrungen mit meinem Alpha-PC (21164 CPU, 550 Mhz, 164 MB RAM, Linux 2.0.32) zu berichten. Ich greife auf die Mesa Bibliothek für eine Gel Simulation zurück, die ich gerade schreibe. Momentan gibt es keine Unterstützung meiner Hardware für Mesa, da die Glide Bibliothek noch nicht für die Alpha-Platform verfügbar ist (bitte: TURBOOOO!!!). Vor kurzem haben Phil Ross und ich die Leistungsfähigkeit seines Pentium PCs (plus 3dfx Karte) mit der meines Alpha PCs und einer Matrox Millenium verglichen und waren dabei ein wenig überrascht, daß die Gel Animation auf meinem Rechner genauso sauber lief, wie auf seinem. Die OpenGL Demos liefen auf meiner Alpha sogar ein wenig besser (solche natürlich, die keine Texturen benutzten). Das heißt, daß die fehlende Hardwarebeschleunigung durch die reine Rechenpower der Alpha CPU kompensiert wurde. Damit sich der Leser von dem Programm ein Bild machen kann: Jedes Bild der Gel Animation beinhaltet eine Gel Struktur, welche aus zehntausenden von Kugeln und Zylindern besteht, plus der Berechnung der Lichtquellen. Auf dem PC war nicht wirklich ein Gel mit so vielen Monomeren zu sehen, da die Berechnungen zuviel für den armen Intel-Prozessor waren. Der Alpha dagegen hatte keine Probleme damit. Ich kann es kaum erwarten, meine Alpha mit der 3dfx Karte und Hardwareunterstützung für Mesa zu sehen.

Literaturverweise

Weitere Artikel zum diesem Thema:


Übersetzung: Harald Radke

This website is maintained by Miguel Angel Sepulveda
© Miguel Angel Sepulveda 1998
LinuxFocus 1998