DGL Wiki - Benutzerbeiträge [de]

DGL-Chat

2010-02-09T19:07:58Z

Wilson: Änderung 24692 von Wilson (Diskussion) wurde rückgängig gemacht.

= DelphiGL-Chat =

Die DGL Community bietet neben der Website, dem Forum und dem Wiki auch ein interaktiven Chat über IRC an.
Den Chat findet man im [http://www.euirc.net/de/ euIRCnet] unter '''#delphigl'''.
In diesen Artikel erfahren Sie, welche Clients es gibt und wie man in diesen Chatroom hinein kommt.

== IRC Chat Client ==
IRC Clients gibt es wie Sand am Meer aber dementsprechend sind auch die Unterschiede.
Da es sich um einen einfachen Zugang handeln soll, ist ein IRC Chatprogram am geeignesten.
Ein Java Applet (wie es z.B. DelphiGL.com unter [http://chat.delphigl.com/ http://chat.delphigl.com/] zur Verfügung stellt) oder ein Webserver basierter Chat sind langsamer und bieten nicht den Funktionsumfang.

Unter Windows:
*[http://www.xchat.org/ XChat]
*[http://www.trillian-messenger.de/ Trillian]
*[http://www.mirc.de/default.php mIRC]
*[http://www.miranda-im.org/ Miranda]
*[http://www.hydrairc.com/ HydraIRC]
*[http://www.pidgin.im/ Pidgin]

Unter Linux:
*[http://www.xchat.org/ XChat]
*[http://www.pidgin.im/ Pidgin]

Ratsam ist XChat zu verwenden, da dieser nicht nur unter Windows,Linux und Mac funktioniert, sondern auch OpenSource und auf dem neusten Stand ist. X-Chat kann unter Windows auch als Precompiled Version geladen werden aber oft sind diese dann kostenpflichtig. Darum ist eine selber compilieren oft praktischer, da es stabiler, kostenlos und oft auch schneller ist. Dies liegt daran, dass das Compilat auf das eigene System vorher angepasst wird.

{{Hinweis|Im Channel solltet Ihr eine der folgenden Personen sehen: [[Benutzer:TAK2004|TAK2004]], [[Benutzer:Frase|Frase]], [[Benutzer:Lord Horazont|Horazont]] oder [[Benutzer:I0n0s|i0n0s]].
Diese Personen sind Inventar und im Normalfall ist immer einer dieser Personen da.}}

== XChat ==

=== Installation von XChat ===
----

==== Compilieren ====
----

Die Source lässt sich unter dem obengenannten Link laden.

#Shell öffnen
#cd /...Ordner wo das Sourcepackage liegt.
#Archive entpacken:<br> tar -xzvf xchat-versionsnummer.tar.gz <br> oder <br> tar -xjvf xchat-versionsnummer.tar.bz2
#cd /...Ordner wo die Source entpackt wurde.../
#Konfigurationsscript ausführen: <br> ./configure
#das Programm compilieren lassen <br> make
#zu root wechseln für eine systemweite Installation <br> su
#sichergehen das man im Sourceordner ist
#xchat installieren <br> make install

==== Binary ====
----

Die binär Datei lässt sich unter dem oben genannten Link laden und mit simplen Klicks unter Windows installieren.
Die Linux Variante kann man als RPM-Datei laden, diese ist eine Linux Installationsdatei und muss mit dem Programm rpm installiert werden.

==== rpm ====
----

#Shell öffnen
#den Ordner mit der rpm öffnen <br> cd /...ordner wo die rpm liegt.../
#das rpm installieren <br> rpm -i xchat-versionsnummer

Es gibt noch eine bequemere Variante, und zwar über ein Packagemanger X-Chat zu beziehen.

===== apt-get =====
----

#Shell öffnen
#zu Root wechseln <br> su -
#apt-get aktualisieren <br> apt-get update
#xchat suchen <br> apt-cache search xchat <br> xchat - A popular and easy to use graphical IRC (chat) client <br>
#das Ergebnis was gefunden wurde installieren <br> apt-get install xchat

===== yum =====
----

#Shell öffnen
#zu Root wechseln <br> su -
#xchat suchen <br> yum search xchat <br> <b>xchat</b>.x86_64 : A popular and easy to use graphical IRC (chat) client <br>
#das Ergebnis was gefunden wurde installieren <br> yum install xchat

=== Konfiguration von XChat ===
----

#X-Chat starten
#oben im Menü X-Chat->Serverliste auswählen
#die einzelnen Nicks eintragen falls die vorigen schon belegt sind
#Hinzufügen drücken und ein Namen auswählen wie "dglchat_server"
#Editieren
#in der Liste ganz oben alle bis auf einen Eintrag "Entfernen"
#den letzten Eintrag "Editieren" und "#irc.euirc.net" eintragen
#ein Häkchen bei "Automatisches Verbinden mit diesem Netzwerk beim Start"
#bei "Zu betretende Channels:" "#delphigl" eintragen
#bei "Zeichensatz:" "UTF-8"
#fenster schließen
#bei "Keine Serverliste beim Start" ein Häkchen machen,"Verbinde" drücken und schließen

== Miranda ==

=== Installation von Miranda ===
----
Die Installation sollte ansich selbsterklärend sein.
Wichtig ist es nur das IRC-PlugIn mitzuinstallieren.

=== Konfiguration von Miranda ===
----
In Miranda-Optionen unter Network sollten folgende Einträge vorhanden sein:
*IRC
*IRC Advanced
*IRC DCC'n CTCP
Wenn nicht sollte unter Plugins kontrolliert werden ob irc.dll ausgewählt ist und läuft.
<br><br>
Gehen wir nun in den Tab IRC:
Unter '''Default network''' wählt ihr euIRCnet: Random server.
{{Hinweis|Wenn man mehrere Netzwerke besuchen will reicht es aus die irc.dll und irc_servers.ini zu kopieren}}
Nick ist euere Nickname. Alternative nick ein alternativer Nick falls der erste schon verwendet wird.
Unter '''Other''' sollte noch 'Rejoin channel if kicked' deaktiviert werden.<br>

Um einen Channel zu joinen klickt man auf das Miranda Icon in der Menuleiste, wählt 'IRC->Join a Channel' aus.
Dort gibt ihr dann #delphigl ein.

DGL-Chat

2010-02-09T19:05:44Z

Wilson: /* Konfiguration von XChat */ Zeichensatzdings raus

= DelphiGL-Chat =

Die DGL Community bietet neben der Website, dem Forum und dem Wiki auch ein interaktiven Chat über IRC an.
Den Chat findet man im [http://www.euirc.net/de/ euIRCnet] unter '''#delphigl'''.
In diesen Artikel erfahren Sie, welche Clients es gibt und wie man in diesen Chatroom hinein kommt.

== IRC Chat Client ==
IRC Clients gibt es wie Sand am Meer aber dementsprechend sind auch die Unterschiede.
Da es sich um einen einfachen Zugang handeln soll, ist ein IRC Chatprogram am geeignesten.
Ein Java Applet (wie es z.B. DelphiGL.com unter [http://chat.delphigl.com/ http://chat.delphigl.com/] zur Verfügung stellt) oder ein Webserver basierter Chat sind langsamer und bieten nicht den Funktionsumfang.

Unter Windows:
*[http://www.xchat.org/ XChat]
*[http://www.trillian-messenger.de/ Trillian]
*[http://www.mirc.de/default.php mIRC]
*[http://www.miranda-im.org/ Miranda]
*[http://www.hydrairc.com/ HydraIRC]
*[http://www.pidgin.im/ Pidgin]

Unter Linux:
*[http://www.xchat.org/ XChat]
*[http://www.pidgin.im/ Pidgin]

Ratsam ist XChat zu verwenden, da dieser nicht nur unter Windows,Linux und Mac funktioniert, sondern auch OpenSource und auf dem neusten Stand ist. X-Chat kann unter Windows auch als Precompiled Version geladen werden aber oft sind diese dann kostenpflichtig. Darum ist eine selber compilieren oft praktischer, da es stabiler, kostenlos und oft auch schneller ist. Dies liegt daran, dass das Compilat auf das eigene System vorher angepasst wird.

{{Hinweis|Im Channel solltet Ihr eine der folgenden Personen sehen: [[Benutzer:TAK2004|TAK2004]], [[Benutzer:Frase|Frase]], [[Benutzer:Lord Horazont|Horazont]] oder [[Benutzer:I0n0s|i0n0s]].
Diese Personen sind Inventar und im Normalfall ist immer einer dieser Personen da.}}

== XChat ==

=== Installation von XChat ===
----

==== Compilieren ====
----

Die Source lässt sich unter dem obengenannten Link laden.

#Shell öffnen
#cd /...Ordner wo das Sourcepackage liegt.
#Archive entpacken:<br> tar -xzvf xchat-versionsnummer.tar.gz <br> oder <br> tar -xjvf xchat-versionsnummer.tar.bz2
#cd /...Ordner wo die Source entpackt wurde.../
#Konfigurationsscript ausführen: <br> ./configure
#das Programm compilieren lassen <br> make
#zu root wechseln für eine systemweite Installation <br> su
#sichergehen das man im Sourceordner ist
#xchat installieren <br> make install

==== Binary ====
----

Die binär Datei lässt sich unter dem oben genannten Link laden und mit simplen Klicks unter Windows installieren.
Die Linux Variante kann man als RPM-Datei laden, diese ist eine Linux Installationsdatei und muss mit dem Programm rpm installiert werden.

==== rpm ====
----

#Shell öffnen
#den Ordner mit der rpm öffnen <br> cd /...ordner wo die rpm liegt.../
#das rpm installieren <br> rpm -i xchat-versionsnummer

Es gibt noch eine bequemere Variante, und zwar über ein Packagemanger X-Chat zu beziehen.

===== apt-get =====
----

#Shell öffnen
#zu Root wechseln <br> su -
#apt-get aktualisieren <br> apt-get update
#xchat suchen <br> apt-cache search xchat <br> xchat - A popular and easy to use graphical IRC (chat) client <br>
#das Ergebnis was gefunden wurde installieren <br> apt-get install xchat

===== yum =====
----

#Shell öffnen
#zu Root wechseln <br> su -
#xchat suchen <br> yum search xchat <br> <b>xchat</b>.x86_64 : A popular and easy to use graphical IRC (chat) client <br>
#das Ergebnis was gefunden wurde installieren <br> yum install xchat

=== Konfiguration von XChat ===
----

#X-Chat starten
#oben im Menü X-Chat->Serverliste auswählen
#die einzelnen Nicks eintragen falls die vorigen schon belegt sind
#Hinzufügen drücken und ein Namen auswählen wie "dglchat_server"
#Editieren
#in der Liste ganz oben alle bis auf einen Eintrag "Entfernen"
#den letzten Eintrag "Editieren" und "#irc.euirc.net" eintragen
#ein Häkchen bei "Automatisches Verbinden mit diesem Netzwerk beim Start"
#bei "Zu betretende Channels:" "#delphigl" eintragen
#fenster schließen
#bei "Keine Serverliste beim Start" ein Häkchen machen,"Verbinde" drücken und schließen

== Miranda ==

=== Installation von Miranda ===
----
Die Installation sollte ansich selbsterklärend sein.
Wichtig ist es nur das IRC-PlugIn mitzuinstallieren.

=== Konfiguration von Miranda ===
----
In Miranda-Optionen unter Network sollten folgende Einträge vorhanden sein:
*IRC
*IRC Advanced
*IRC DCC'n CTCP
Wenn nicht sollte unter Plugins kontrolliert werden ob irc.dll ausgewählt ist und läuft.
<br><br>
Gehen wir nun in den Tab IRC:
Unter '''Default network''' wählt ihr euIRCnet: Random server.
{{Hinweis|Wenn man mehrere Netzwerke besuchen will reicht es aus die irc.dll und irc_servers.ini zu kopieren}}
Nick ist euere Nickname. Alternative nick ein alternativer Nick falls der erste schon verwendet wird.
Unter '''Other''' sollte noch 'Rejoin channel if kicked' deaktiviert werden.<br>

Um einen Channel zu joinen klickt man auf das Miranda Icon in der Menuleiste, wählt 'IRC->Join a Channel' aus.
Dort gibt ihr dann #delphigl ein.

OpenGL Smooth

2010-01-05T19:51:10Z

Wilson: Rechtschreibung

[[OpenGL]] besitzt, neben den unter [[Antialiasing]] vorgestellten Methoden, eine weitere Möglichkeit Kanten-Antialiasing zu realisieren. Diese können mit [[glEnable]] mit den Parametern GL_POINT_SMOOTH, GL_LINE_SMOOTH bzw. GL_POLYGON_SMOOTH aktiviert werden.

=Technik=
Wenn der Smooth-Wert für ein [[Primitive]] aktiviert ist, so werden im Fall von Punkten und Linien bereits andere Pixel vom [[Rasterisierung|Rasterizer]] generiert. Zusätzlich wird für jedes generierte [[Fragment]] noch ein Deckungs-Wert berechnet, welcher angibt wie viel Prozent des Fragmentes von dem entsprechenden [[Primitive]] bedeckt werden.

Dieser Deckungs-Wert wird nach allen anderen Berechnungen mit dem Alpha-Wert des Fragmentes multipliziert. Aus diesem Grund hängt diese Art von Antialiasing auch mit [[Blending]] zusammen, wodurch das Zeichnen üblicherweise mit Tiefensortierung erfolgen muss (was gleichzeitig der größte Nachteil an dieser Methode ist).

==Punkte==
Werden (größere) Punkte mit aktiviertem GL_POINT_SMOOTH gerendert, so wird offensichtlich aus dem Quadrat ein richtiger Kreis. Auch ohne aktiviertem [[Blending]] (mittels [[glEnable]]( GL_BLEND ) ) hätte man hier also bereits ein Kreisform, aber natürlich ohne geglätteten Rand.

[[Bild:GL_POINT_SMOOTH_deaktiviert.png]] [[Bild:GL_POINT_SMOOTH_aktiviert.png]]

''4-Fach vergrößerter Punkt links ohne und recht mit GL_POINT_SMOOTH.''

==Linien==
Werden Linien mit aktiviertem GL_LINE_SMOOTH gerendert, so wird offensichtlich aus dem Trapez (mehrere 1-Pixel Linien entweder nebeneinander oder übereinander) ein Quader. Dies hat (vor allem bei breiteren Linien) ebenfalls auch Auswirkungen wenn [[Blending]] deaktiviert ist.

[[Bild:GL_LINE_SMOOTH_deaktiviert.png]] [[Bild:GL_LINE_SMOOTH_aktiviert.png]]

''4-Fach vergrößerte Linie links ohne und recht mit GL_LINE_SMOOTH.''

==Polygone==
Polygone (also Triangles, Quads, Triangle-Strips, Triangle-Fans und Polygone) verändern ihr Erscheinungsbild mit deaktivierten [[Blending]] kaum. Mit aktiviertem [[Blending]] werden aber natürlich die Kanten geglättet.

=Probleme=
Bei Polygonen tauchen die größten Problem auf, und zwar so große, dass es von vielen Grafikkarten gar nicht unterstützt wird. Vor allem bei aktiviertem GL_POLYGON_SMOOTH kommt es also des öfteren vor, dass in den Softwaremodus umgeschaltet wird, und nicht einmal dann kann man sicher sein dass es funktioniert. Und wenn es doch funktioniert so erwartet einem häufig bereits die nächste Überraschung.

Das Problem ist, dass zwei aneinanderliegende Dreiecke häufig einen Spalt aufweisen. Da die [[Primitive]]n GL_QUADS, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN und GL_POLYGON üblicherweise ebenfalls in Dreiecke aufgeteilt werden, entsteht dieser Spalt auch dort. Und wäre dies nicht schon genug so kann ein einzelnes Dreieck an einer [[Clipping Plane]] oder dem [[Frustum]] ebenfalls noch in 4 kleiner Dreiecke aufgesplittet werden, wo wir wiederum diesen Spalt antreffen.

Also GL_POLYGON_SMOOTH ist mit äußerster Vorsicht zu genießen.

=OpenGL Funktionen=
*[[glEnable]] um GL_POINT_SMOOTH, GL_LINE_SMOOTH bzw. GL_POLYGON_SMOOTH zu aktivieren.
*[[glHint]] um den [[OpenGL]]-Treiber zu bitten eine schnellere oder eine schönere Berechnungsmethode zu verwenden.

Diskussion:Matrix

2008-12-05T15:26:54Z

Wilson: Die Seite wurde neu angelegt: Bei der mxn-nxr-Matrix-Matrix Multiplikation ist ein Fehler: Bei dem Element unten links muss es nicht heißen "3*7+0+1*4" sondern "3*5+0+4*7". Deshalb ist dann auch da...

Bei der mxn-nxr-Matrix-Matrix Multiplikation ist ein Fehler: Bei dem Element unten links muss es nicht heißen "3*7+0+1*4" sondern "3*5+0+4*7". Deshalb ist dann auch das Ergebnis 43 und nicht 25.
Am besten wäre es sowieso, die gescannten Sachen durch schöne LaTeX-Formeln zu ersetzen. --[[Benutzer:Wilson|Wilson]] 15:26, 5. Dez. 2008 (UTC)

Heightmap

2008-09-05T19:30:15Z

Wilson: Ressourcenliste durch Kommas getrennt

==Konzept==
Eine Heightmap ist ein 2-dimensionales Array, dass Informationen über eine Landschaft enthält. Dazu wird einfach an jedem Knoten der entsprechende Höhenwert gespeichert. Zum Beispiel eine zufällige Landschaft:
<pascal>
var
i,j: integer;
heightmap: array[0..width, 0..depth] of single;
begin
for i := 0 to width do
for j := 0 to depth do
heightmap[i,j] := PerlinNoise2D(i,j, octaves, persistence);
end;
</pascal>
{{Hinweis|Es kann auch aus einem Graustufenbitmap geladen werden, z.B. je heller ein Punkt, desto höher die Landschaft an dieser Stelle}}

==Bewertung==
Der Vorteil von Heightmaps ist, dass sie sehr leicht zu implementieren sind. Ein Nachteil ist jedoch, dass immer nur ein Höhenwert pro Knoten gespeichert werden kann und man so keine Felsvorsprünge oder Höhlen realisieren kann.
Eine interessante Möglichkeit ist, Heightmaps mit Algorithmen wie [[Perlin Noise]] zur Laufzeit zur erstellen. Desweiteren kann man [[LOD]] benutzen um das Rendern von Heightmaps zu beschleunigen.

==Ressourcen==
[[Tutorial Terrain1]], [[Tutorial Terrain2]], [[Tutorial Terrain3]]

Shaderlimitiert

2008-08-17T19:51:15Z

Wilson: Kommas

Obwohl Shader eine der neuesten Errungenschaften bei Grafikkarten sind, besitzen sie natürlich auch Nachteile. Bevor es Shader gab, wurden alle Daten, die an die Grafikkarte geschickt wurden, nach fix vorgegebenen, einfachen Algorithmen (siehe [[Feste Funktionspipeline]]) behandelt, welche nur durch verhältnismäßig wenige Schalter oder Parameter beeinflusst werden konnten. Diese Spezialisierung bringt erst den großen Vorteil einer Grafikkarte gegenüber einer (oder sogar gegenüber einer 2ten) CPU, da diese Berechnungen nicht als Programm, sondern fast ausschließlich elektronisch realisiert wurden und großteils immer noch werden.

Durch Shader (oder wie die OpenGL-Extensionnamen Vertex- und Fragment-program besser verdeutlichen) hat sich dies nun geändert. Ein Teil der [[Feste Funktionspipeline|festen Funktionspipeline]] wird durch einen programmierbaren Prozessor ersetzt, welcher es erlaubt die vorgegebenen Algorithmen zu verändern. Diese Freiheit geht jedoch auf Kosten der Geschwindigkeit. Hinzu kommt noch, dass der Programmierer beliebige Instruktionen geben kann, also in schlimmen Fällen auch viele, langsame und vielleicht sogar unnötige Befehle, welche natürlich die Geschwindigkeit der Grafikkarte beeinflussen. Im Endeffekt sind jedoch Shader nur als Erhöhung der Laufzeitkomplexität für Vertices bzw. Fragmente zu sehen, wodurch Shader einen (jedoch einen verhältnismäßig wichtigen) Beitrag zur [[Vertexlimitiert|Vertexlimitierung]] bzw. zur [[Füllrate|Füllratenlimitierung]] darstellen.

Füllrate

2008-08-17T19:48:53Z

Wilson:

Die Füllrate einer Grafikkarte beschreibt die [[Fragment]]e, die je Sekunde berechnet werden können. Da der Aufwand für diese Berechnungen jedoch sehr unterschiedlich sein kann, sind diese Angaben mit Vorsicht zu geniesen, denn meistens werden die Angaben für sehr primitive Rendereinstellungen gemacht (untexturiert, kein [[Fragment]] [[Shader]], ...).

Der Begriff Füllratengebunden bezieht sich darauf, dass die Anzahl der [[Fragment]]e, die berechnet werden können, im Normalfall der ausschlaggebende Punkt für die Framerate ist. Dies ist natürlich nicht auf allen Grafikkarten gleich, jedoch sind die Verhältnisse zwischen [[Vertex]]anzahl und [[Fragment]]anzahl, die je Sekunde gezeichnet werden können, meistens doch recht ähnlich.

Um zu testen, ob eine Applikation füllratengebunden ist, reicht es aus, die Applikation mit niedrigerer Auflösung laufen zu lassen und zu schauen, ob sich an der Geschwindigkeit Unterschiede bemerkbar machen.

Einige Möglichkeiten, um die Füllrate zu schonen (und somit füllratengebundene Applikationen zu beschleunigen), sind:
*Auflösung verringern
*Objekte von vorne nach hinten zeichnen, um Gebrauch vom [[glDepthFunc|Tiefentest]] zu machen, welcher Fragmente recht früh verwirft
*Gebrauch vom [[glAlphaFunc|Alphatest]] machen, um [[Fragment]]e mit einem sehr niedrigem Alpha-Wert sehr früh zu verwerfen
*Die Rendereinstellungen je [[Fragment]] herabsetzen, also weniger Texturen, kürzerer [[Fragment]] [[Shader]], ...
*Die Szene weniger oft rendern (weniger Rendering Passes)
*[[Occlusion Culling]]
*[[MipMaps|Mipmapping]] bei Texturen, um die Lokalität der Texturzugriffe zu erhöhen
*[[Bilineare Filterung]] (anstatt linear, trilinear oder [[Anisotropes Filtern|anisotropes Filtern]])
Wenn viele Rendering Passes, die recht komplex sind, notwendig sind, so kann man auch im ersten Rendering Pass die gesamte Szene nur in den Tiefenbuffer zeichnen (diese Technik wird beispielsweise in Quake 3 verwendet). Bei den nächsten Passes werden dadurch alle nicht sichtbaren Fragmente sofort durch den Tiefentest verworfen.

Einige Dinge, die '''keinen''' oder nur wenig Einfluss auf die Füllrate nehmen:
*[[LOD|Level of Detail]]
*[[Vertex]] [[Shader]]
*[[Frustum Culling]]
*Texturgröße, sofern genug Videospeicher vorhanden ist und [[MipMaps]] verwendet wird.

BlueBook

2008-04-29T18:32:32Z

Wilson: Purple-Book-Satz verständlicher gemacht

== Was ist das? ==
Das OpenGL Bluebook ist das Referenzhandbuch zu den GL, GLU und GLX Befehlen. Hier werden alle Befehle mit
:Name
:Spezifikation
:Paramter
:Beschreibung
aufgelistet.<br>

Entspricht also quasi der [[OpenGL-Funktionsübersicht]] dieses Wikis.

Bildet zusammen mit dem [[RedBook]] die [[PurpleBook]] genannte "Official OpenGL Library" des "OpenGL Architecture Review Board"<p></p>

==Siehe Auch==
[[RedBook]], [[OrangeBook]]

RedBook

2008-04-29T18:32:04Z

Wilson: Purple-Book-Satz verständlicher gemacht

== Was ist das? ==
Das OpenGL Redbook ist die Dokumentation welche Ursprünglich von SGI zu [[OpenGL]] geschrieben wurde. <br>
Im Redbook werden alle Techniken von OpenGL, unter anderem mit Beispielen (in C) und Bildern, erklärt. <br>
Bildet zusammen mit dem [[BlueBook]] die [[PurpleBook]] genannte "Official OpenGL Library" des "OpenGL Architecture Review Board"<p></p>

== Bezugsquellen ==
Mittlerweile wird das Redbook vom Addison-Wesley Verlag vertrieben. Eine deutsche Version ist im Buchhandel verfügbar.<p></p>

Hin und wieder taucht eine englische Version des Redbooks auch im Internet auf. Eine deutsche Übersetzung samt Aktualisierung dieser Version wurde ursprünglich von der DelphiGL-Comunity angestrebt. Da aber alle Versuche der Absprache mit dem Copyrightinhaber Addison-Wesley scheiterten, wurde das DGL-Wiki als Ersatz ins Leben gerufen.

==Siehe Auch==
[[BlueBook]], [[OrangeBook]]

Diskussion:Tutorial Frustum Culling

2008-04-17T18:17:04Z

Wilson: Die Seite wurde geleert.

Diskussion:Tutorial Frustum Culling

2008-04-17T18:15:54Z

Wilson: Die Seite wurde neu angelegt: == Große Objekte == Was dem ganzen fehlt, ist die Betrachtung von Kugeln/Quadern (ganz allgemein: von Objekten aus min. 2 Punkten), die so groß sind, dass zwar die Ec...

== Große Objekte ==
Was dem ganzen fehlt, ist die Betrachtung von Kugeln/Quadern (ganz allgemein: von Objekten aus min. 2 Punkten), die so groß sind, dass zwar die Eckpunkte allesamt außerhalb des Bildschirms liegen, der Teil dazwischen aber innerhalb.
Gut - das dürfte nicht häufig der Fall sein, aber es ist ein Fehlverhalten. [[Benutzer:Wilson|Wilson]]

Tutorial Matrix2

2008-04-12T22:02:44Z

Wilson: /* Nachwort */ URL zu Matrix Control angepasst

=Matrizen und Matrixmanipulationen=

== Vorwort ==
Willkommen bei meinem 2. Tutorial.<br>
In letzter Zeit traten im Forum verstärkt fragen wie ''"Wie positioniere ich Objekte richtig?"'' und ''"Ich komm mit den Matrizen net klar. Könnt ihr helfen?"'' auf. Dies war Anlass für mich ein weiteres Tutorial zum Thema Matrizen zu schreiben. Ich werde versuchen viel mit Bildern und Gleichnissen zu arbeiten. Wer aber das ganze Angebot zum Thema "Matrix" nutzen will sollte ruhig auch einen Blick auf Phobeus Matrixtutorial ([[Tutorial_lektion3]]) und auf den Wikiartikel zum Thema [[Matrix]] werfen.

== Matrizen in OpenGL ==

OpenGL kennt 3 Matrizen. Wer OpenGL programmieren will sollte diese auch kennen:
* '''GL_MODELVIEW''' - Die Modelviewmatrix
: Die Modelviewmatrix sollte immer dann aktiviert sein, wenn ihr an die Grafikkarte [[Vertex]]daten senden wollt. Diese Matrix wird auf die Position der Vertices, die mit [[glVertex]] gesendet werden angewandt. Ebenso beeinflusst sie die Ausrichtung der [[Normalen]], die mit Hilfe von [[glNormal]] gesetzt werden. Kurz, alles was mit den Objekten eurer Welt zu tun hat, erfordert die Aktivierung dieser Matrix.
* '''GL_PROJECTION''' - Die Projektionsmatrix
: Diese Matrix wird selten gebraucht. Sie bestimmt, wie am Ende alles angezeigt wird. Sie bestimmt quasi die Eigenschaften der "Kamera".
* '''GL_TEXTURE''' - Die Texturmatrix
: Diese Matrix wird auf die Texturkoordinaten angewandt, mit der Folge, dass sich die Texturen auf den Oberflächen bewegen.

Diese 3 Matrizen können per [[glMatrixMode]] aktiviert werden. Dabei kann immer nur eine Matrix aktiv sein. Wenn ihr z.B. {{INLINE_CODE|glMatrixMode(GL_MODELVIEW)}} aufgerufen habt, dann sagt man "Die Modelviewmatrix ist die '''''aktuelle Matrix'''''". Alle Matrixmanipulationen (wir kommen gleich dazu was das ist) wirken sich ''nur'' auf die ''aktuelle Matrix'' aus.

== Kurze Matrixtheorie ==
''Was sind Matrizen?'' <br>
Matrizen sind aufgebaut wie Tabellen. Das tolle daran ist - man kann damit rechnen. <br>
''"Gaaaaanz toll! Jetzt rechnen die schon mit Tabellen..."''<br>
So schlimm ist das gar nicht. Denn das Rechnen übernimmt OpenGL für uns. Ihr müsst nur wissen, dass wann immer ihr einen Befehl wie [[glTranslate]], [[glRotate]] oder [[glScale]] verwendet, ihr eine Matrix mit der ''aktuellen Matrix'' multipliziert.
{{Hinweis|Wenn ihr wissen wollt, wie man Matrizen miteinander multipliziert, dann lest euch einmal den Artikel "[[Matrix]]" durch und auch das dort verlinkte PDF "CompGeoScript".}}

== Wie sehen Matrizen aus? ==
In "echt" sehen Matrizen wie Tabellen voller Zahlen aus. <br>
Will man sich eine Matrix grafisch vorstellen, sollte man sich ein 3 dimensionales Gitter vorstellen. Dieses Gitter ist das Koordinatensystem der Matrix. Wenn ihr mit [[glTranslate]], [[glRotate]] oder [[glScale]] die Matrix manipuliert, dann verändert ihr die Position des Koordinatenursprungs (glTranslate), die Ausrichtung der Achsen (glRotate) oder die Maße (glScale). Im dritten Teil des Tutorials gehe ich auf die Auswirkungen dieser Befehle noch einmal genauer ein.

= Die drei OpenGL Matrizen =

== GL_PROJECTION ==
Ich möchte zuerst einmal die Projektionsmatrix vorstellen. Diese Matrix wird meist nur am Rande erwähnt, macht aber einen verdammt wichtigen Job: Sie projeziert den Inhalt der Welt auf den Bildschirm.

Wenn ihr der Projektionsmatrix per [[glLoadMatrix]] eine Matrix zuweist, die nur Nullen enthält, werdet ihr feststellen, dass ihr nichts seht. Ihr habt damit nämlich die Projektionsmatrix ausgeschaltet und da wir ja was sehen wollen, unterlassen wir das in Zukunft lieber ;).

''Aber was kann man dann mit der Projektionsmatrix machen (,außer sie nicht auszuschalten ;-) )?'' <br>
Bei der Vorstellung der einzelnen Matrizen erwähnte ich bereits die "Kamera". Um gleich mal eins festzustellen: Ein Objekt "Kamera" existiert nicht. Das einzigste was man von der "Kamera" mitbekommt ist die Ausgabe. Und wie wir gerade gelernt haben ist welcher Teil für die Ausgabe zuständig? Richtig! Die Projektionsmatrix. Sie ist unsere "Kamera".

Kommt jetzt aber bitte nicht auf die Idee, eure Projektionsmatrix per '''glTranslate''' und '''glRotate''' irgendwohin zu bewegen... Das ist nämlich gar nicht die Aufgabe der Projektionsmatrix. Ihre Aufgabe ist "das Abbild für die Ausgabe zu manipulieren".

Im Ausgangszustand ([[glLoadIdentity]] wurde für die Projektionsmatrix aufgerufen), gibt die Projektionsmatrix das Bild der Welt unverändert aus. Wenn man '''glTranslate''' auf die Projektionsmatrix anwendet, dann verschiebt man nicht die Welt, sondern sagt der Projektionsmatrix, dass sie das gesehene Bild verschieben soll.

Befehle wie [[gluPerspective]] und [[glOrtho]] sind typische Befehle zum einstellen der Projektionsmatrix. Diese Befehle bestimmen nämlich in welcher Form die Ausgabe gemacht wird. Entweder perspektivisch verzerrt (gluPerspective) oder durch Parallelprojektion (glOrtho).

Wenn man die Projektionsmatrix manipuliert, ist das vergleichbar mit dem Austauschen des Objektivs bei einer Kamera. Man könnt sogar über die Projektionsmatrix einen "Fischauge" Effekt erzeugen... (Aber fragt mich bitte nicht, wie die Matrix dazu aussieht... ;-) Falls ihrs wißt, einfach im Forum posten. Ich wäre interessiert.)

== GL_MODELVIEW ==
Wie bereits erwähnt ist die Modelviewmatrix die wichtigste Matrix in der OpenGL Welt, denn sie wirkt sich auf Ausrichtung und Position aller Primitive und damit Objekte in der OpenGL Welt aus. Ohne Daten in der Modelviewmatrix, kann die Projektionsmatrix auch nichts ausgeben.

Wenn ihr [[Vertex]]daten an die Grafikkarte übermittelt solltet ihr die Modelviewmatrix aktiviert haben. Positionsangaben wie z.B. {{INLINE_CODE|glVertex3f(1,0,1);}} beziehen sich auf das aktuelle Koordinatensystem. Das Koordinatensystem ist quasi der Teil der Matrix mit dem ihr arbeitet, und den ihr euch vorstellen könnt (/müßt.).<br>
Wie ihr bereits wisst kann man mit den Befehlen [[glTranslate]], [[glRotate]] und [[glScale]] das Koordinatensystem manipulieren. Dadurch seit ihr in der Lage beim "bauen" von Objekten mit "lokalen Koordinaten" zu arbeiten.

=== lokale und globale Koordinaten ===
''Worin unterscheiden sich lokale und globale Koordinaten?'' <br>
Um diese Frage zu klären bedarf es eines kleinen Beispiels:

Stellt euch vor, ihr wollt zwei Würfel zeichnen. Der eine soll um den Punkt (3,4,5) mit einer Kantenlänge von 1 erstellt werden, der andere soll um den Punkt (1,2,3) mit Kantenlänge 2 und dazu 30° um die Y-Achse gedreht werden.

Wenn man mit '''globalen''' Koordinaten arbeitet lässt man die Matrix so wie sie ist (verzichtet also auf die 3 genannten Befehle) und schreibt die Koordinaten der Eckpunkte per Hand hin:
<pascal>glBegin(GL_QUADS);
//Vorderseite erster Würfel
glVertex3f(2,5,6);
glVertex3f(2,3,6);
glVertex3f(4,3,6);
glVertex3f(4,5,6);
//Nächste Seite
[...]

//Vorderseite zweiter Würfel
glVertex3f(0,3,4);
glVertex3f(0,1,4);
glVertex3f(2,1,4);
glVertex3f(2,3,4);
[...]

glEnd;
</pascal>

Bei '''lokalen''' Koordinaten bewegt man zuerst den Koordinatenursprung an die Stelle an die der Würfel entstehen soll, richtet dann wenn nötig die Achsen entsprechend aus, und kann dann '''lokale''' Koordinaten übergeben. Lokal bedeutet hier relativ zum aktuellen Koordinatensystem.

''Aber was soll das für einen Vorteil haben?'' <br>
Dem ein oder anderen ist vielleicht aufgefallen, dass wir 2x das selbe Objekt zeichnen sollen. Der einzigste Unterschied besteht in der Position, Ausrichtung und Größe/Scalierung. Um Arbeit zu sparen erstellt man deshalb ein Unterprogramm welches einen Einheitswürfel (Kantenlänge 1) rendert, und ruft vor dem zeichnen einfach die passende Kombination aus glTranslate, glRotate und glScale auf:

<pascal>procedure zeichneWuerfel;
begin
glBegin(GL_QUADS);
glVertex3f(-0.5, 0.5, 0.5);
glVertex3f(-0.5,-0.5, 0.5);
glVertex3f( 0.5,-0.5, 0.5);
glVertex3f( 0.5, 0.5, 0.5);
[...]
glEnd;
end;

begin
glPushMatrix;
glTranslatef(3,4,5);
zeichneWuerfel;
glPopMatrix;
glPushMatrix;
glTranslatef(1,2,3);
glRotatef(30,0,1,0);
glScalef(2,2,2);
zeichneWuerfel;
glPopMatrix;
end;
</pascal>

Wie ihr seht, haben lokale Koordinaten den Vorteil, dass man wiederverwendbaren Code schreiben kann. Bei globalen Koordinaten muss für jedes Objekt eigener Code geschrieben werden (und wenn sich das Objekt bewegt dann wieder...).

Dreimal dürft ihr raten, welche Methode häufiger verwendet wird. ;-)
{{Hinweis|Modeller wie 3D Studio Max benutzen globale Koordinaten beim exportieren der Modelle. Dies hat den Vorteil, dass beim importieren einer ganzen 3DS Szene, die Objekte gleich an der richtigen Position stehen, und nicht erst ausgerichtet werden müssen.}}

== GL_TEXTURE ==
Dieser Matrix sollte endlich mehr Aufmerksamkeit geschenkt werden. Sie kann nämlich mit den Texturen in der Szene einiges anfangen...

Aber der Reihe nach:

Wie ihr vielleicht schon im [[Tutorial_lektion4|Einsteigertutorial 4 - Texturen]] gelesen habt, sind Texturkoordinaten immer so, dass {{INLINE_CODE|[[glTexCoord2f]](0,0)}} die obere linke Ecke und {{INLINE_CODE|glTexCoord2f(1,1)}} die untere Rechte Ecke der Textur betrifft. Wie die Textur außerhalb dieses Bereichs aussieht bestimmt ihr mittels [[glTexParameter]] und dem Parametern '''GL_TEXTURE_WRAP_S''' und '''GL_TEXTURE_WRAP_T'''.

Nun stellt euch einmal vor, ihr habt 2 Quads die beide die selbe Textur bekommen sollen. Einziger Unterschied ist, dass bei dem einen Quad der Inhalt der Textur um 20° in Uhrzeigerrichtung gedreht ist. Blöd, oder? Das heißt ja jetzt, dass ihr in eurem Zeichenprogramm eine weitere Textur erstellen müßt, um das zweite Quad zu texturieren oder die Texturkoordinaten per Hand ändern müsst. <br>
'''STOP!''' Ihr hab es sicherlich schon mitbekommen: Dieses Szenario kann leicht mit der Texturmatrix gelößt werden. Und zwar so...

<pascal>procedure drawTexturedQuad;
begin
glBegin(GL_QUADS);
glTexCoord(0,0); glVertex3f(-1, 1,0);
glTexCoord(0,1); glVertex3f(-1,-1,0);
glTexCoord(1,1); glVertex3f( 1,-1,0);
glTexCoord(1,0); glVertex3f( 1, 1,0);
glEnd;
end;

begin
glMatrixMode(GL_MODELVIEW);
glBindTexture(GL_TEXTURE_2D, texID);
glTranslatef(-2,0,0);
drawTexturedQuad;

glMatrixMode(GL_TEXTURE);
glRotatef(20,0,0,1);

glMatrixMode(GL_MODELVIEW);
glTranslatef(4,0,0);
drawTexturedQuad;
end;</pascal>
''Was ist hier geschehn? ''<br>
Durch die vorherige Aktivierung der Texturmatrix wirkt sich das nachfolgende glRotate nicht auf die Modelle der Szene sondern auf die Texturkoordinaten aus. Auf gut deutsch: OpenGL dreht vor dem rendern des zweiten Quads die Textur um 20°.

Wenn ihr beim rotieren der Texturmatrix, bei jedem Renderdurchlauf den Winkel um ein Stück erhöht passiert was?... Richtig! Eure Textur dreht sich auf eurem Quad... Das is dann quasi eure erste Animation... Und das ohne ein Objekt zu bewegen... Cool, oder?

= Auswirkungen von Matrixmanipulationen - oder "Wie positioniere ich meine Objekte richtig?"=
In diesem Teil des Tutorials möchte ich euch zeigen wie die 3 Befehle '''glTranslate, glRotate''' und '''glScale''' eure aktuelle Matrix verändern. Ich bleibe hierbei im 2 dimensionalen Raum, da sonst die Skizzen zu unübersichtlich werden. (Die Befehle sind dabei natürlich die selben wie für 3D Manipulationen. Ich ignoriere nur einfach immer die Y-Angaben.)

Zuersteinmal zum warm werden: <br>
[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|So stelle ich mir eine 2D-Matrix vor.]]

==glTranslate==
{{INLINE_CODE|[[glTranslate]](a,b,c)}} verschiebt den Koordinatenursprung des aktuellen Koordinatensystems um ''a'' Einheiten in die Richtung der X-Achse, um ''b'' Einheiten in die Richtung der Y-Achse und um ''c'' Einheiten in die Richtung der Z-Achse.

[[Bild:Tutorial Matrix2 Translate.png|framed|center|Das passiert bei einer Translation um 3.5 Einheiten in X und -3 Einheiten in Z-Richtung.]]

==glRotate==
{{INLINE_CODE|[[glRotate]](w,x,y,z)}} rotiert das Koordinatensystem um ''w'' Grad um die Rotationsachse welche durch (0,0,0) und (''x,y,z'') verläuft. '''glScale richtet also die Achsen neu aus.''' (Die Richtung der Achsen ist z.B. wichtig für glTranslate)

[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Das passiert bei einer Rotation um 45° mit der Y-Achse als Rotationsachse.]]

==glScale==
{{INLINE_CODE|[[glScale]](x,y,z)}} skaliert die Maße der Koordinatenachsen (Bestimmt also wie lange "eine Einheit" wirklich ist). Wenn ''x,y'' oder ''z'' größer als 1 ist, werden die Maßeinheiten der entsprechenden Achse gestreckt, wenn die Werte kleiner 1 sind gestaucht. (Wenn die Werte gleich 0 sind verschwindet die Szene auf nimmer wieder sehn(, da hilft dann nur noch glLoadIdentity um die Matrix wieder nutzbar zu machen), sind die Werte gleich 1 verändert sich nichts.)

''x,y'' und ''z'' muss man sich als Prozentangaben vorstellen. Will man die Szene in X-Richtung um das doppelte (also 200%) vergrößern/strecken muss ''x'' gleich 2 sein. Will man die Y-Richtung auf ein Zehntel (also 10%) verkürzen/stauchen muss ''y'' gleich 0.1 sein.

[[Bild:Tutorial Matrix2 Scale.png|framed|center|Das passiert bei einer Skalierung. Wie ihr seht, sind die Seiten unterschiedlich skaliert worden (X-Achse: 80%, Z-Achse: 60%).]]

==Kombination - Translate vor Rotate==
Wird Translate vor Rotate aufgerufen, bewegt sich der Koordinatenursprung zuerst an den Zielpunkt (über glTranslate angegeben). Anschließend werden die Achsen neu ausgerichtet (durch glRotate).

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glTranslatef(3.5,0,-3);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Translate.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die jeweils vorhergehende Veränderung bestehend bleibt, und die Basis für die nachfolgende Änderung bildet.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, dreht sich ein anschließend gezeichnetes Objekt um die durch glTranslate angegeben Position.

==Kombination - Rotate vor Translate==
Wird Rotate vor Translate aufgerufen, werden zuerst die Achsen neu ausgerichtet und dann der Koordinatenursprung bezüglich dieser neuen Achsen verschoben.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glRotatef(45, 0, 1, 0);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Nachdem glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde. Man sieht, dass die vorhergehende Rotation die Verschieberichtung beeinflusst.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, bewegt sich ein nach glTranslate gezeichnetes Objekt auf einer Kreisbahn um den Koordinatenursprung wie er beim Aufruf von glRotate aktuell war. Der Radius der Kreisbahn wird durch glTranslate bestimmt.

Wenn man die beiden Ergebnisse direkt vergleicht sieht man, dass die Reihenfolge von Bedeutung für das Ergebniss ist. Das die Unterschiede so "klein" ausfallen liegt nur daran, dass bei rotate nicht mit größeren Winkeln rotiert wurde.

<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Erst Rotiert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Erst Verschoben]]
|}</div>

==Kombination - Scale vor Rotate==
Die Rotation wird nur von der Richung, nicht aber der Länge der Achsen beeinflusst. Der Winkel um den gedreht wird, bleibt von der Skalierung unberührt (45° bleiben 45°. Die Achsen zeigen anschließend jeweils in die gleiche Richtung)

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glScalef(0.8, 1, 0.6);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die Skalierung den Winkel nicht beeinflusst. Das Koordinatensystem wurde korrekt um 45° gedreht.]]
|}</div>

Der direkte Vergleich zeigt, dass die Skalierung keinen Effekt auf den Winkel hatte. Beide Koordinatensysteme sind gleich ausgerichtet:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Rotate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Skaliert]]
|}</div>

==Kombination - Scale vor Translate==
Die Verschiebung ist Abhängig von der Ausrichtung der Achsen (glRotate) und der Maße der Achsen (glScale). Aus diesem Grunde beeinflusst glScale die nachfolgenden Translationen.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glScalef(0.8, 1, 0.6);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|}</div>

Der direkte Vergleich zeigt, dass sich die Skalierung auf die Verschiebung auswirkt. Denn obwohl der Verschiebung in die gleiche Richtung und um den selben Wert erfolgt, sind die Resultate nicht identisch. Dies liegt daran, dass glScale die Maße verändert hat. Die Verschiebung in X-Richtung erreicht dadurch nur 80% und in Z-Richtung sogar nur 60% der unskalierten Transformation:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Translate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Skaliert]]
|}</div>

=Nachwort=
7 Stunden sind vorbei und das Tutorial ist auf eine ordentliche Länge angewachsen. Ich hoffe ich konnte euch die OpenGL Matrizen etwas näher bringen.

Wer jetzt denkt ''"Bilder sind mir zu statisch!"'', dem möchte ich noch diese Programme ans Herz legen:
<div align="center">
{|{{Prettytable}}
!Name
!Hersteller
!Beschreibung
|-
|[http://www.delphigl.com/forum/viewtopic.php?p=37378#37378 '''Matrix2 - Skizzenrenderer''']
|Flash
|Dieses Programm habe ich geschrieben um die Skizzen für dieses Tutorial zu erstellen. Es wurde so modifiziert, dass man beliebige Kombinationen von glTranslate, glRotate und glScale anzeigen kann.
|-
|[http://www.phobeus.de/hosting/shared/pixelpracht/main.php?s=opengl&t=1&p=2 '''Matrix Control''']
|Lithander
|Das Programm erlaubt euch zu beobachten, wie die Matrizen sich bei den einzelnen Befehlen verändern und wie die Ausgabe aussieht. Besonderheit an diesem Programm ist, dass ihr die Matrizen auch per Hand manipulieren könnt.
|}</div>

Sollten immer noch Unklarheiten bestehen bleibt das Forum natürlich auch weiterhin die Anlaufstelle Nummer1. Dies betrifft auch euer Feedback zum Tutorial.

MfG
: Flash ('''Kevin Fleischer''')

{{TUTORIAL_NAVIGATION|[[Tutorial_2D]]|-}}

[[Kategorie:Tutorial|Matrix2]]

Tutorial Matrix2

2008-04-12T21:59:31Z

Wilson: /* GL_TEXTURE */ Tippfehler

=Matrizen und Matrixmanipulationen=

== Vorwort ==
Willkommen bei meinem 2. Tutorial.<br>
In letzter Zeit traten im Forum verstärkt fragen wie ''"Wie positioniere ich Objekte richtig?"'' und ''"Ich komm mit den Matrizen net klar. Könnt ihr helfen?"'' auf. Dies war Anlass für mich ein weiteres Tutorial zum Thema Matrizen zu schreiben. Ich werde versuchen viel mit Bildern und Gleichnissen zu arbeiten. Wer aber das ganze Angebot zum Thema "Matrix" nutzen will sollte ruhig auch einen Blick auf Phobeus Matrixtutorial ([[Tutorial_lektion3]]) und auf den Wikiartikel zum Thema [[Matrix]] werfen.

== Matrizen in OpenGL ==

OpenGL kennt 3 Matrizen. Wer OpenGL programmieren will sollte diese auch kennen:
* '''GL_MODELVIEW''' - Die Modelviewmatrix
: Die Modelviewmatrix sollte immer dann aktiviert sein, wenn ihr an die Grafikkarte [[Vertex]]daten senden wollt. Diese Matrix wird auf die Position der Vertices, die mit [[glVertex]] gesendet werden angewandt. Ebenso beeinflusst sie die Ausrichtung der [[Normalen]], die mit Hilfe von [[glNormal]] gesetzt werden. Kurz, alles was mit den Objekten eurer Welt zu tun hat, erfordert die Aktivierung dieser Matrix.
* '''GL_PROJECTION''' - Die Projektionsmatrix
: Diese Matrix wird selten gebraucht. Sie bestimmt, wie am Ende alles angezeigt wird. Sie bestimmt quasi die Eigenschaften der "Kamera".
* '''GL_TEXTURE''' - Die Texturmatrix
: Diese Matrix wird auf die Texturkoordinaten angewandt, mit der Folge, dass sich die Texturen auf den Oberflächen bewegen.

Diese 3 Matrizen können per [[glMatrixMode]] aktiviert werden. Dabei kann immer nur eine Matrix aktiv sein. Wenn ihr z.B. {{INLINE_CODE|glMatrixMode(GL_MODELVIEW)}} aufgerufen habt, dann sagt man "Die Modelviewmatrix ist die '''''aktuelle Matrix'''''". Alle Matrixmanipulationen (wir kommen gleich dazu was das ist) wirken sich ''nur'' auf die ''aktuelle Matrix'' aus.

== Kurze Matrixtheorie ==
''Was sind Matrizen?'' <br>
Matrizen sind aufgebaut wie Tabellen. Das tolle daran ist - man kann damit rechnen. <br>
''"Gaaaaanz toll! Jetzt rechnen die schon mit Tabellen..."''<br>
So schlimm ist das gar nicht. Denn das Rechnen übernimmt OpenGL für uns. Ihr müsst nur wissen, dass wann immer ihr einen Befehl wie [[glTranslate]], [[glRotate]] oder [[glScale]] verwendet, ihr eine Matrix mit der ''aktuellen Matrix'' multipliziert.
{{Hinweis|Wenn ihr wissen wollt, wie man Matrizen miteinander multipliziert, dann lest euch einmal den Artikel "[[Matrix]]" durch und auch das dort verlinkte PDF "CompGeoScript".}}

== Wie sehen Matrizen aus? ==
In "echt" sehen Matrizen wie Tabellen voller Zahlen aus. <br>
Will man sich eine Matrix grafisch vorstellen, sollte man sich ein 3 dimensionales Gitter vorstellen. Dieses Gitter ist das Koordinatensystem der Matrix. Wenn ihr mit [[glTranslate]], [[glRotate]] oder [[glScale]] die Matrix manipuliert, dann verändert ihr die Position des Koordinatenursprungs (glTranslate), die Ausrichtung der Achsen (glRotate) oder die Maße (glScale). Im dritten Teil des Tutorials gehe ich auf die Auswirkungen dieser Befehle noch einmal genauer ein.

= Die drei OpenGL Matrizen =

== GL_PROJECTION ==
Ich möchte zuerst einmal die Projektionsmatrix vorstellen. Diese Matrix wird meist nur am Rande erwähnt, macht aber einen verdammt wichtigen Job: Sie projeziert den Inhalt der Welt auf den Bildschirm.

Wenn ihr der Projektionsmatrix per [[glLoadMatrix]] eine Matrix zuweist, die nur Nullen enthält, werdet ihr feststellen, dass ihr nichts seht. Ihr habt damit nämlich die Projektionsmatrix ausgeschaltet und da wir ja was sehen wollen, unterlassen wir das in Zukunft lieber ;).

''Aber was kann man dann mit der Projektionsmatrix machen (,außer sie nicht auszuschalten ;-) )?'' <br>
Bei der Vorstellung der einzelnen Matrizen erwähnte ich bereits die "Kamera". Um gleich mal eins festzustellen: Ein Objekt "Kamera" existiert nicht. Das einzigste was man von der "Kamera" mitbekommt ist die Ausgabe. Und wie wir gerade gelernt haben ist welcher Teil für die Ausgabe zuständig? Richtig! Die Projektionsmatrix. Sie ist unsere "Kamera".

Kommt jetzt aber bitte nicht auf die Idee, eure Projektionsmatrix per '''glTranslate''' und '''glRotate''' irgendwohin zu bewegen... Das ist nämlich gar nicht die Aufgabe der Projektionsmatrix. Ihre Aufgabe ist "das Abbild für die Ausgabe zu manipulieren".

Im Ausgangszustand ([[glLoadIdentity]] wurde für die Projektionsmatrix aufgerufen), gibt die Projektionsmatrix das Bild der Welt unverändert aus. Wenn man '''glTranslate''' auf die Projektionsmatrix anwendet, dann verschiebt man nicht die Welt, sondern sagt der Projektionsmatrix, dass sie das gesehene Bild verschieben soll.

Befehle wie [[gluPerspective]] und [[glOrtho]] sind typische Befehle zum einstellen der Projektionsmatrix. Diese Befehle bestimmen nämlich in welcher Form die Ausgabe gemacht wird. Entweder perspektivisch verzerrt (gluPerspective) oder durch Parallelprojektion (glOrtho).

Wenn man die Projektionsmatrix manipuliert, ist das vergleichbar mit dem Austauschen des Objektivs bei einer Kamera. Man könnt sogar über die Projektionsmatrix einen "Fischauge" Effekt erzeugen... (Aber fragt mich bitte nicht, wie die Matrix dazu aussieht... ;-) Falls ihrs wißt, einfach im Forum posten. Ich wäre interessiert.)

== GL_MODELVIEW ==
Wie bereits erwähnt ist die Modelviewmatrix die wichtigste Matrix in der OpenGL Welt, denn sie wirkt sich auf Ausrichtung und Position aller Primitive und damit Objekte in der OpenGL Welt aus. Ohne Daten in der Modelviewmatrix, kann die Projektionsmatrix auch nichts ausgeben.

Wenn ihr [[Vertex]]daten an die Grafikkarte übermittelt solltet ihr die Modelviewmatrix aktiviert haben. Positionsangaben wie z.B. {{INLINE_CODE|glVertex3f(1,0,1);}} beziehen sich auf das aktuelle Koordinatensystem. Das Koordinatensystem ist quasi der Teil der Matrix mit dem ihr arbeitet, und den ihr euch vorstellen könnt (/müßt.).<br>
Wie ihr bereits wisst kann man mit den Befehlen [[glTranslate]], [[glRotate]] und [[glScale]] das Koordinatensystem manipulieren. Dadurch seit ihr in der Lage beim "bauen" von Objekten mit "lokalen Koordinaten" zu arbeiten.

=== lokale und globale Koordinaten ===
''Worin unterscheiden sich lokale und globale Koordinaten?'' <br>
Um diese Frage zu klären bedarf es eines kleinen Beispiels:

Stellt euch vor, ihr wollt zwei Würfel zeichnen. Der eine soll um den Punkt (3,4,5) mit einer Kantenlänge von 1 erstellt werden, der andere soll um den Punkt (1,2,3) mit Kantenlänge 2 und dazu 30° um die Y-Achse gedreht werden.

Wenn man mit '''globalen''' Koordinaten arbeitet lässt man die Matrix so wie sie ist (verzichtet also auf die 3 genannten Befehle) und schreibt die Koordinaten der Eckpunkte per Hand hin:
<pascal>glBegin(GL_QUADS);
//Vorderseite erster Würfel
glVertex3f(2,5,6);
glVertex3f(2,3,6);
glVertex3f(4,3,6);
glVertex3f(4,5,6);
//Nächste Seite
[...]

//Vorderseite zweiter Würfel
glVertex3f(0,3,4);
glVertex3f(0,1,4);
glVertex3f(2,1,4);
glVertex3f(2,3,4);
[...]

glEnd;
</pascal>

Bei '''lokalen''' Koordinaten bewegt man zuerst den Koordinatenursprung an die Stelle an die der Würfel entstehen soll, richtet dann wenn nötig die Achsen entsprechend aus, und kann dann '''lokale''' Koordinaten übergeben. Lokal bedeutet hier relativ zum aktuellen Koordinatensystem.

''Aber was soll das für einen Vorteil haben?'' <br>
Dem ein oder anderen ist vielleicht aufgefallen, dass wir 2x das selbe Objekt zeichnen sollen. Der einzigste Unterschied besteht in der Position, Ausrichtung und Größe/Scalierung. Um Arbeit zu sparen erstellt man deshalb ein Unterprogramm welches einen Einheitswürfel (Kantenlänge 1) rendert, und ruft vor dem zeichnen einfach die passende Kombination aus glTranslate, glRotate und glScale auf:

<pascal>procedure zeichneWuerfel;
begin
glBegin(GL_QUADS);
glVertex3f(-0.5, 0.5, 0.5);
glVertex3f(-0.5,-0.5, 0.5);
glVertex3f( 0.5,-0.5, 0.5);
glVertex3f( 0.5, 0.5, 0.5);
[...]
glEnd;
end;

begin
glPushMatrix;
glTranslatef(3,4,5);
zeichneWuerfel;
glPopMatrix;
glPushMatrix;
glTranslatef(1,2,3);
glRotatef(30,0,1,0);
glScalef(2,2,2);
zeichneWuerfel;
glPopMatrix;
end;
</pascal>

Wie ihr seht, haben lokale Koordinaten den Vorteil, dass man wiederverwendbaren Code schreiben kann. Bei globalen Koordinaten muss für jedes Objekt eigener Code geschrieben werden (und wenn sich das Objekt bewegt dann wieder...).

Dreimal dürft ihr raten, welche Methode häufiger verwendet wird. ;-)
{{Hinweis|Modeller wie 3D Studio Max benutzen globale Koordinaten beim exportieren der Modelle. Dies hat den Vorteil, dass beim importieren einer ganzen 3DS Szene, die Objekte gleich an der richtigen Position stehen, und nicht erst ausgerichtet werden müssen.}}

== GL_TEXTURE ==
Dieser Matrix sollte endlich mehr Aufmerksamkeit geschenkt werden. Sie kann nämlich mit den Texturen in der Szene einiges anfangen...

Aber der Reihe nach:

Wie ihr vielleicht schon im [[Tutorial_lektion4|Einsteigertutorial 4 - Texturen]] gelesen habt, sind Texturkoordinaten immer so, dass {{INLINE_CODE|[[glTexCoord2f]](0,0)}} die obere linke Ecke und {{INLINE_CODE|glTexCoord2f(1,1)}} die untere Rechte Ecke der Textur betrifft. Wie die Textur außerhalb dieses Bereichs aussieht bestimmt ihr mittels [[glTexParameter]] und dem Parametern '''GL_TEXTURE_WRAP_S''' und '''GL_TEXTURE_WRAP_T'''.

Nun stellt euch einmal vor, ihr habt 2 Quads die beide die selbe Textur bekommen sollen. Einziger Unterschied ist, dass bei dem einen Quad der Inhalt der Textur um 20° in Uhrzeigerrichtung gedreht ist. Blöd, oder? Das heißt ja jetzt, dass ihr in eurem Zeichenprogramm eine weitere Textur erstellen müßt, um das zweite Quad zu texturieren oder die Texturkoordinaten per Hand ändern müsst. <br>
'''STOP!''' Ihr hab es sicherlich schon mitbekommen: Dieses Szenario kann leicht mit der Texturmatrix gelößt werden. Und zwar so...

<pascal>procedure drawTexturedQuad;
begin
glBegin(GL_QUADS);
glTexCoord(0,0); glVertex3f(-1, 1,0);
glTexCoord(0,1); glVertex3f(-1,-1,0);
glTexCoord(1,1); glVertex3f( 1,-1,0);
glTexCoord(1,0); glVertex3f( 1, 1,0);
glEnd;
end;

begin
glMatrixMode(GL_MODELVIEW);
glBindTexture(GL_TEXTURE_2D, texID);
glTranslatef(-2,0,0);
drawTexturedQuad;

glMatrixMode(GL_TEXTURE);
glRotatef(20,0,0,1);

glMatrixMode(GL_MODELVIEW);
glTranslatef(4,0,0);
drawTexturedQuad;
end;</pascal>
''Was ist hier geschehn? ''<br>
Durch die vorherige Aktivierung der Texturmatrix wirkt sich das nachfolgende glRotate nicht auf die Modelle der Szene sondern auf die Texturkoordinaten aus. Auf gut deutsch: OpenGL dreht vor dem rendern des zweiten Quads die Textur um 20°.

Wenn ihr beim rotieren der Texturmatrix, bei jedem Renderdurchlauf den Winkel um ein Stück erhöht passiert was?... Richtig! Eure Textur dreht sich auf eurem Quad... Das is dann quasi eure erste Animation... Und das ohne ein Objekt zu bewegen... Cool, oder?

= Auswirkungen von Matrixmanipulationen - oder "Wie positioniere ich meine Objekte richtig?"=
In diesem Teil des Tutorials möchte ich euch zeigen wie die 3 Befehle '''glTranslate, glRotate''' und '''glScale''' eure aktuelle Matrix verändern. Ich bleibe hierbei im 2 dimensionalen Raum, da sonst die Skizzen zu unübersichtlich werden. (Die Befehle sind dabei natürlich die selben wie für 3D Manipulationen. Ich ignoriere nur einfach immer die Y-Angaben.)

Zuersteinmal zum warm werden: <br>
[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|So stelle ich mir eine 2D-Matrix vor.]]

==glTranslate==
{{INLINE_CODE|[[glTranslate]](a,b,c)}} verschiebt den Koordinatenursprung des aktuellen Koordinatensystems um ''a'' Einheiten in die Richtung der X-Achse, um ''b'' Einheiten in die Richtung der Y-Achse und um ''c'' Einheiten in die Richtung der Z-Achse.

[[Bild:Tutorial Matrix2 Translate.png|framed|center|Das passiert bei einer Translation um 3.5 Einheiten in X und -3 Einheiten in Z-Richtung.]]

==glRotate==
{{INLINE_CODE|[[glRotate]](w,x,y,z)}} rotiert das Koordinatensystem um ''w'' Grad um die Rotationsachse welche durch (0,0,0) und (''x,y,z'') verläuft. '''glScale richtet also die Achsen neu aus.''' (Die Richtung der Achsen ist z.B. wichtig für glTranslate)

[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Das passiert bei einer Rotation um 45° mit der Y-Achse als Rotationsachse.]]

==glScale==
{{INLINE_CODE|[[glScale]](x,y,z)}} skaliert die Maße der Koordinatenachsen (Bestimmt also wie lange "eine Einheit" wirklich ist). Wenn ''x,y'' oder ''z'' größer als 1 ist, werden die Maßeinheiten der entsprechenden Achse gestreckt, wenn die Werte kleiner 1 sind gestaucht. (Wenn die Werte gleich 0 sind verschwindet die Szene auf nimmer wieder sehn(, da hilft dann nur noch glLoadIdentity um die Matrix wieder nutzbar zu machen), sind die Werte gleich 1 verändert sich nichts.)

''x,y'' und ''z'' muss man sich als Prozentangaben vorstellen. Will man die Szene in X-Richtung um das doppelte (also 200%) vergrößern/strecken muss ''x'' gleich 2 sein. Will man die Y-Richtung auf ein Zehntel (also 10%) verkürzen/stauchen muss ''y'' gleich 0.1 sein.

[[Bild:Tutorial Matrix2 Scale.png|framed|center|Das passiert bei einer Skalierung. Wie ihr seht, sind die Seiten unterschiedlich skaliert worden (X-Achse: 80%, Z-Achse: 60%).]]

==Kombination - Translate vor Rotate==
Wird Translate vor Rotate aufgerufen, bewegt sich der Koordinatenursprung zuerst an den Zielpunkt (über glTranslate angegeben). Anschließend werden die Achsen neu ausgerichtet (durch glRotate).

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glTranslatef(3.5,0,-3);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Translate.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die jeweils vorhergehende Veränderung bestehend bleibt, und die Basis für die nachfolgende Änderung bildet.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, dreht sich ein anschließend gezeichnetes Objekt um die durch glTranslate angegeben Position.

==Kombination - Rotate vor Translate==
Wird Rotate vor Translate aufgerufen, werden zuerst die Achsen neu ausgerichtet und dann der Koordinatenursprung bezüglich dieser neuen Achsen verschoben.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glRotatef(45, 0, 1, 0);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Nachdem glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde. Man sieht, dass die vorhergehende Rotation die Verschieberichtung beeinflusst.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, bewegt sich ein nach glTranslate gezeichnetes Objekt auf einer Kreisbahn um den Koordinatenursprung wie er beim Aufruf von glRotate aktuell war. Der Radius der Kreisbahn wird durch glTranslate bestimmt.

Wenn man die beiden Ergebnisse direkt vergleicht sieht man, dass die Reihenfolge von Bedeutung für das Ergebniss ist. Das die Unterschiede so "klein" ausfallen liegt nur daran, dass bei rotate nicht mit größeren Winkeln rotiert wurde.

<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Erst Rotiert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Erst Verschoben]]
|}</div>

==Kombination - Scale vor Rotate==
Die Rotation wird nur von der Richung, nicht aber der Länge der Achsen beeinflusst. Der Winkel um den gedreht wird, bleibt von der Skalierung unberührt (45° bleiben 45°. Die Achsen zeigen anschließend jeweils in die gleiche Richtung)

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glScalef(0.8, 1, 0.6);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die Skalierung den Winkel nicht beeinflusst. Das Koordinatensystem wurde korrekt um 45° gedreht.]]
|}</div>

Der direkte Vergleich zeigt, dass die Skalierung keinen Effekt auf den Winkel hatte. Beide Koordinatensysteme sind gleich ausgerichtet:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Rotate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Skaliert]]
|}</div>

==Kombination - Scale vor Translate==
Die Verschiebung ist Abhängig von der Ausrichtung der Achsen (glRotate) und der Maße der Achsen (glScale). Aus diesem Grunde beeinflusst glScale die nachfolgenden Translationen.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<pascal>
glScalef(0.8, 1, 0.6);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</pascal>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|}</div>

Der direkte Vergleich zeigt, dass sich die Skalierung auf die Verschiebung auswirkt. Denn obwohl der Verschiebung in die gleiche Richtung und um den selben Wert erfolgt, sind die Resultate nicht identisch. Dies liegt daran, dass glScale die Maße verändert hat. Die Verschiebung in X-Richtung erreicht dadurch nur 80% und in Z-Richtung sogar nur 60% der unskalierten Transformation:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Translate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Skaliert]]
|}</div>

=Nachwort=
7 Stunden sind vorbei und das Tutorial ist auf eine ordentliche Länge angewachsen. Ich hoffe ich konnte euch die OpenGL Matrizen etwas näher bringen.

Wer jetzt denkt ''"Bilder sind mir zu statisch!"'', dem möchte ich noch diese Programme ans Herz legen:
<div align="center">
{|{{Prettytable}}
!Name
!Hersteller
!Beschreibung
|-
|[http://www.delphigl.com/forum/viewtopic.php?p=37378#37378 '''Matrix2 - Skizzenrenderer''']
|Flash
|Dieses Programm habe ich geschrieben um die Skizzen für dieses Tutorial zu erstellen. Es wurde so modifiziert, dass man beliebige Kombinationen von glTranslate, glRotate und glScale anzeigen kann.
|-
|[http://www.phobeus.de/hosting/pixelpracht/main.php?s=opengl&t=1&p=2 '''Matrix Control''']
|Lithander
|Das Programm erlaubt euch zu beobachten, wie die Matrizen sich bei den einzelnen Befehlen verändern und wie die Ausgabe aussieht. Besonderheit an diesem Programm ist, dass ihr die Matrizen auch per Hand manipulieren könnt.
|}</div>

Sollten immer noch Unklarheiten bestehen bleibt das Forum natürlich auch weiterhin die Anlaufstelle Nummer1. Dies betrifft auch euer Feedback zum Tutorial.

MfG
: Flash ('''Kevin Fleischer''')

{{TUTORIAL_NAVIGATION|[[Tutorial_2D]]|-}}

[[Kategorie:Tutorial|Matrix2]]

Matrix

2008-04-12T21:53:49Z

Wilson: Tippfehler

==Matrix / Matrizen==

===Übersicht===
Eine Matrix ist im wesentlichen nichts anderes als das, was man in der Programmierung als zweidimensionales Array kennt. Dabei beschreibt eine Matrix eine [http://de.wikipedia.org/wiki/Lineare_Abbildung lineare Abbildung], was als Information bei Rechnungen sehr wichtig ist.

'''Wichtig:''' Für den Einstieg in OpenGl ist ein tiefergehendes Verständnis von Matrizen noch nicht notwendig um bereits interessante Ergebnisse zu erzielen. Es genügt am Anfang zu wissen, daß man damit Verscheibungen, Drehungen und Streckungen beschreiben kann und daß die Reihenfolge der Befehle zum Manipulieren der Matrix wichtig ist. Wer also noch seine ersten Erfahrungen mit OpenGl macht, kann sich zuerst in unseren [[Tutorial|Tutorials]] informieren und erst anschließend hier wieder vorbeischauen.

'''Anmerkung:''' Wir wollen mit den Definitionen hier nur soweit gehen, wie es für ein Verständnis von OpenGl Geometrie wichtig ist. In der Linearen Algebra werden einige der hier gegebenen Begriffe deutlich genauer und häufig auch abstrakter betrachtet. Dies würde jedoch unseren kleinen Rahmen deutlich sprengen.

===Definition===
Matrizen sind Abbildungen auf Vektorräumen ganzzahliger Dimension. Für alle weiteren Betrachtungen seien deshalb die Zahlen n,m und r aus dem Bereich {1,2,3,4,5,...}, also den natürlichen Zahlen ohne Null, fest vorgegeben.

====R<sup>n</sup> Vektorräume====
Um Matrizen definieren zu können, müssen wir zuerst Vektorräume definieren. Ein Vektorraum (V,*,+) ist eine Menge Vektoren V zusammen mit einer Skalar-Multiplikation * und einer Addition auf Vektoren, auf denen man vernünftig Vektorrechnung betreiben kann.

Hat man also zwei Vektoren v<sub>1</sub> und v<sub>2</sub>, so kann man diesen eindeutig eine Summe zuordnen:
v<sub>3</sub> = v<sub>1</sub> + v<sub>2</sub> .

Ausserdem kann man sie mit einem Skalar c aus den reelen Zahlen strecken:
v<sub>4</sub> = c*v<sub>1</sub> .

'''Beispiel''': Der Standardvektorraum R<sup>n</sup>:
Ein Vektor v aus dem R<sup>n</sup> besteht aus n reelen Zahlen ( seinen Komponenten ), deren Reihenfolge wichtig ist. Man kann also v auch in Form seiner Komponenten schreiben:

[[Bild:Vektorkomponenten.jpg|center]]

Häufig wird kein Unterschied dahingehend gemacht, ob der Vektor als Zeile oder als Spalte geschrieben wird. Bei der später definierten Matrixmultiplikation wird dies jedoch durchaus interessant, wir wollen uns also erstmal darauf beschränken, daß auch die Schreibweise
v=(v<sub>1</sub>,...,v<sub>n</sub>)
für unseren Vektor v eine legitime, als Text einfacher verfassbare Schreibweise darstellt. Bei der später definierten Multiplikation mit einer Matrix der Vektor aber immer als Spalte betrachtet wird.

Um unseren Vektorraum zu vervollständigen, brauchen wir nach Definition nun auch noch eine Addition und eine (Skalar-)Multiplikation. Die Addition geschieht komponentenweise. Hat man also einen zweiten Vektor b = v=(b<sub>1</sub>,...,b<sub>n</sub>), so ist die Addition definiert durch:

[[Bild:Vektoraddition.jpg|center]]

Die Multiplikation eines Vektors v mit einem reellen Faktor λ entspricht einer Streckung des Vektors um λ, was durch Multiplikation aller Komponenten von v mit λ erreicht wird:

[[Bild:Vektorskalarmultiplikation.jpg|center]]

Es ergeben sich die von den normalen reelen Zahlen bekannten Rechenregeln:
λ*( v + b ) = λ*v + λ*b ,
d.h. man kann Skalare einfach aus Klammern ausmultiplizieren oder wieder hineinziehen. Man beachte aber, daß die Multiplikation von Vektoren mit Vektoren nicht definiert ist( Siehe auch [[Vektorprodukt]], [[Standard Skalarprodukt]] ) .

Ist unser n gerade die Zahl 3 bzw. 2, so kann man durch den R<sup>n</sup> gerade den 3-Dimensionalen bzw. 2-Dimensionalen Anschauungsraum darstellen. Vektoren kann man dann sogar zeichnen und bekommt eine bildliche Vorstellung. Vektoren werden zu einer Darstellung von Pfeilen, die eine Richtung beschreiben oder ausgehend vom Nullpunkt des Koordinatensystems einen Punkt definieren:

[[Bild:Vektorvorstellung.jpg|center]]

====Lineare Abbildungen auf dem R<sup>n</sup> in den R<sup>m</sup>====
Weiter kann man Abbildungen f, die als Parameter Vektoren des R<sup>n</sup> annehmen und diese in den R<sup>m</sup> abbilden, definieren. Insbesondere kann man Abbildungen definieren, die linear sind, d.h. daß f folgende Eigenschaften erfüllt:

[[Bild:Lineare Abbildungen.jpg|center]]

und zwar für alle a,b aus R<sup>n</sup> und alle λ aus den reellen Zahlen R. Interessant ist, daß solche Abbildungen die Rechenregeln aus unserer Vektorraumdefinition erhalten. Sehr wichtig ist jedoch: Solche Abbildungen existieren. Die einfachste ist die, die alle Vektoren aus R<sup>n</sup>
auf die 0 abbildet ( die 0 ist der Vektor des R<sup>m</sup>, in dem alle Komponenten gleich 0 ist. ). Tatsächlich gibt es deutlich mehr dieser Abbildungen und alle lassen sich als Matrizen darstellen. Und umgekehrt: Mit Matrizen lassen sich alle lineare Abbildungen auf unseren Vektorräumen beschreiben.

====mxn-Matrizen und ihre Anwendung auf Vektoren====
Wie bereits angesprochen, sind Matrizen also 2 Dimensionale Felder aus rellen Zahlen:

[[Bild:mxnMatrix.jpg|center]]

Die a<sub>ij</sub> werden dann die Koeffizienten der Matrix genannt. Nun wollen wir das Anwenden der Matrix A aus R<sup>mxn</sup> auf einen Vektor x definieren:

[[Bild:mxnMatrixAnwendungaufx.jpg|center]]

Beispiel:
[[Bild:AnwendungsbeispielMatrizen.jpg|center]]

Am Bild erkennt man auch, warum die Matrix-Vektor Multiplikation ( " Anwendung " ) auch als Zeile mal Spalte bezeichnet wird, denn die Koeffizienten einer Zeile der Matrix werden der Reihe nach mit den Koeffizienten der "Spalte" des Vektors multipliziert. Dieses Verfahren kann man erweitern, indem man Vektoren als Matrizen interpretiert, die nur eine Spalte haben. Schreibt man mehrere Vektoren nebeneinander, kann man auf jede dieser Spalten die Matrix A darauf anwenden:

====mxn-nxr-Matrix-Matrix Multiplikation====
Man hat also eine mxn-Matrix A und eine nxr-Matrix B, die man Spaltenweise als Vektoren versteht:

[[Bild:zerlegungMatrixInEinzelvektoren.jpg|center]]

Bei der Multiplikation von A mit B, wird dann einfach A auf die Vektoren b<sub>i</sub> angewendet.

[[Bild:MatrixMatrixMultiplikation.jpg|center]]

Beispiel:

[[Bild:MatrixMatrixMultiplikationBeispiel.jpg|center]]

====Eigenschaften====
Diese Multiplikation hat eine Reihe von Eigenschaften:
* Versteht man die Matrizen A,B als lineare Abbildungen auf Vektoren x aus dem R<sup>n</sup> und y aus R<sup>r</sup>, also f(x) = A*x und g(y) = B*y und ist A eine mxn-Matrix, sowie B eine nxr Matrix, dann ist die Abbildung f(g(y)) eine Lineare Abbildung, die beschrieben ist durch
f(g(y)) = A*B*y .
* Daraus ergibt sich, da schon die Definitions-Vektorräume verschieden sind, daß in den meisten Fällen nicht gilt: A*B=B*A . Wer sich dies genauer überlegt, stellt fest, daß das 2. Produkt nur dann definiert ist, wenn A und B beides nxn-Matrizen sind. Aber selbst in diesem Fall ist es im Allgemeinen ein Unterschied, ob ich A*B oder B*A rechne ( Das führt schließlich zu der Tatsache, warum man in OpenGl aufpassen muss, ob man zuerst rotiert und dann verschiebt oder umgekehrt: Diese Operationen werden durch Matrizenmultiplikationen implementiert! ).

* Matrizen stellen Lineare Abbildungen dar, es gilt also:
A*(x+x') = A*x + A*x'
A*(B+C) = A*B + A*C
A*(λ*x) = λ*A*x
* Man nennt eine Gleichung A*x = b ein Lineares Gleichungssystem, wenn A und b bekannt und x gesucht ist. Es interessiert dann, ob es eine Lösung gibt und welche das ( sofern sie eindeutig ist ) ist.

===Siehe Auch===
Es gibt noch eine Menge weiterer Eigenschaften, und Funktionen, die in Bezug auf Matrizen höchst interessant sind:

[[Matrix_Transposition]], [[Determinante]], [[Matrix_Inversion]], [[Gauss_Algorithmus]]

==Matrizen in OpenGl==
===Die drei OpenGL Matrizen===
In OpenGL gibt es drei 4x4-Matrizen welche alle mit Hilfe von [[glTranslate]], [[glScale]], [[glRotate]],[[glMultMatrix]],[[glLoadMatrix]] und [[glLoadIdentity]] bearbeitet werden können. Welche Matrix von diesen Funktionen beeinfusst wird, kann durch [[glMatrixMode]] gesteuert werden.

Die 3 Matrizen sind:

====GL_PERSPECTIVE====

Sollte nur für die Festlegung der Perspektive genutzt werden.

====GL_MODELVIEW====

Legt Position und Größe des zu zeichnenden Primitiven fest

====GL_TEXTURE====

Beinhaltet Informationen wie Texturen dargestellt werden.

Noch mehr Informationen zu den Matrizen und was sie bewirken gibts im [[Tutorial Matrix2]].

===Aufbau einer OpenGL-Matrix===

Möchte man mit OpenGL an einer bestimmten Stelle etwas zeichnen, so kann man mit Hilfe von [[glTranslate]] und [[glRotate]] die Modelview-Matrix so manipulieren, dass etwa der mit [[glVertex]] übergebene Eckpunkt (0/0/0) im Weltkoordinaten System nicht mehr in der Mitte liegt. Alle Punkte erscheinen scheinbar in einen zweiten Koordinaten System welches etwas verdreht, vegrößert oder verrutsch liegen kann.

Dieses zweite Koordinaten-System wird durch eine 4x4-Matrix, also einem zwei dimensionenlen Array mit vier Spalten und Zeilen, beschrieben.

Damit besser verstanden werden kann, wie dies funktioniert, wird die Funktionsweise anhand eines zwei dimensionalen Koordinaten System demonstiert.

Möchte man in einem einfachen 2D Koordiaten-System den Punkt (X/Y) antragen, so hängt man X mal den Vektor der X-Achse aneinander, und Y mal den Vektor der Y-Achse.

[[Bild:KoordinatenSystemA.png]]

Um die Lage und Größe eines Koordinatensystems zu beschreiben werden also einmal die Vektoren benötiget die 1 '''L'''ängen '''E'''inheit meiner Achsen beschreiben, sowie ein Vektor der ihre Position in Anhängigkeit zum übergeordneten Koordinatensystems beschreibt.

[[Bild:KoordinatenSystemB.png]]

Wie bereits bemerkt, müssten die Matrizen eigentlich 3x3-Matrizen sein, da sie ja auf dem 3D-Raum operieren sollen. Damit lassen sich jedoch keine Verschiebungen beschreiben, weswegen man bei der übergabe von Vertexdaten mit [[glVertex]] im Hintergrund eine 4. Koordinate
w neben (x,y,z) einführt. Diese hat, wenn nicht explizit über glVertex4x angegeben, den Wert 1 und so lassen sich mit 4x4 Matrizen auch Verschiebungen beschreiben:

{|
|- align="center"
| X || X || X || X || |
|- align="center"
| Y || Y || Y || Y || |
|- align="center"
| Z || Z || Z || Z || |
|- align="center"
| W || W || W || W || |
|}
So wirkt jede Zeile der OpenGl-Matrix auf genau die entsprechende
Koordinate des Vertex nach der Multiplikation mit einem Vertex (x,y,z,1). Ist die letzte Zeile der Matrix (0,0,0,1), hat also die Matrix die Form:

{|
|- align="center"
| X || X || X || X || |
|- align="center"
| Y || Y || Y || Y || |
|- align="center"
| Z || Z || Z || Z || |
|- align="center"
| 0 || 0 || 0 || 1 || |
|}
Dann beschreibt die letzte Spalte der Matrix gerade die Verschiebung unseres Vertices, wie man mit der oben definierten Anwendung einer Matrix auf einen Vektor leicht überprüft. Am Ende wird die w-Koordinate, sofern sie 1 ist, wieder verworfen - was sie auch bleibt, denn die letzte Zeile der OpenGl Matrix ist gerade so gewählt, daß dies sichergestellt ist. Nur bei der endgültigen Darstellung auf den Monitor kommt der w-Koordinate noch eine weitere Bedeutung zu, weshalb Projektionsmatrizen ( erzeugt durch [[glOrtho]], [[glFrustum]], ... ) sich an Regel der letzten Zeile (0,0,0,1) nicht halten.

Folgendes Format könnte man nutzen, um eine Matrix mit [[glGetFloatv]] auszulesen oder mit [[glLoadMatrix]] zu setzen.

TVektor = '''record''' X,Y,Z,W:glFloat '''end''';
TMatrix = '''array'''[(mat_XAchse,mat_YAchse,mat_ZAchse,mat_Position)]'''of''' TVektor;
PMatrix = ^TMatrix;

Man beachte dabei, daß OpenGl Matrizen '''Spaltenweise''' im Speicher ablegt sind. Siehe dazu auch: [[glMultMatrix]]



===Zum leichteren Verständnis===
''Dieser Abschnitt ist nicht für fortgeschrittene 3D Entwickler gedacht, sollte aber Anfängern die immer noch nicht wissen, was Matrizen eigentlich in OpenGL machen einen leichteren Einblick verschaffen.''

Um sich Matrizen in OpenGL leichter vorzustellen, kann man folgendes Bild benutzen:

* Die 3D-Welt ist in einer Art Glaskasten abgelegt in dem es keine Physik gibt (Dinge können in der Luft schweben u.ä.).
* Matrizen sind Maschinen/Greifarme.
* Matrizen sind die einzige Möglichkeit in den Glaskasten hinein zu greifen.

Wie wir weiter oben bereits gelernt haben sind Matrizen ja eigentlich Tabellen mit Zahlen. Diese Zahlen sind die Stellschrauben an unseren "Greifarmen". Mit diesen Stellschrauben können wir die Greifarme im Glaskasten positionieren. Durch den OpenGL-Befehl [[glMatrixMode]] können wir auswählen welchen der beiden Arme wir gerade steuern.

'''ModelView - Der Objektmanipulator'''
: Wird diese Matrix auf ein Objekt angewendet, ändert sich je nach Einstellung der Matrix dessen Position, Ausrichtung, Größe usw. (Man kann sogar den kompletten Glaskasten damit verschieben.) (Beispiel: Wirft man einen Würfel in eine Drehungsmatrix, kommt am Ende ein gedrehter Würfel raus.)

'''PerspectivMatrix - Die Kameralinse'''
: Diese Maschine ist nur für die Ausgabe zuständig. Man kann über die Stellschrauben einstellen, welche Art der Projektion (Parallel-, Perspektivisch-,...), und wie nah und wie weit Objekte maximal von der Kamera entfernt sein dürfen, um sichtbar zu sein.

Wer nun auf den Geschmack gekommen ist und mittels [[glLoadMatrix]] mal selber die Stellschrauben einer der beiden Matrizen ändern möchte, der sollte sich das sehr gute '''Mathe Script''' zum Thema '''Computer Geometrie''' einmal ansehen (siehe Links). Das eben vermittelte Bild mag zwar helfen. Die Theorie muss aber verstanden werden um damit arbeiten zu können.

===Siehe auch===
[[glMatrixMode]], [[glGet]], [[glLoadIdentity]], [[glLoadMatrix]], [[glTranslate]], [[glRotate]], [[glScale]], [[Quaternion|Quaternionen]]

===Links===
*[[Tutorial_Nachsitzen|Tutorial: Nachsitzen]]
*[http://www-user.tu-chemnitz.de/~pester/Lehre/CompGeo.pdf Recht umfangreiches, gut verständliches Script zum Thema "Computer Geometrie" (PDF)]

Lichtsäule

2008-04-12T21:39:15Z

Wilson: Tippfehler

{{Bildwunsch|Ein Bild einer Lichtsäule aus einem Spiel wäre hier schön.}}
= Lichtsäulen =
Unter dem Begriff "Lichtsäulen" kann man viele Effekte fassen. Das einzigste was alle Effekte gemein haben ist, dass sie meist mit [[transparent]]en, hellen [[Textur]]en arbeiten um ein Leuchten zu simulieren.

Diese Lichtsäulen werden in Fantasy-Spielen oft benutzt um Anwendung von Zaubersprüchen auf Figuren oder Gegenständen zu verdeutlichen.

== Verschiedene Möglichkeiten ==

=== Partikelsysteme===
Lichtsäulen können auch einfach nur aufsteigende leuchtende Punkte sein. Um diese zur erzeugen werden [[Partikelsystem]]e verwendet.

=== Zylinder ===
Ein Zylinder kann auch eine Lichtsäule darstellen. In dem man hierbei die Textur-[[Matrix]] durch [[glTranslate|Verschiebung]]en so manipuliert, dass das Endresultat zum Beispiel sich nach unten bewegende '''Lichtringe''' simuliert.

=== Zwei sich überkreuzende Rechtecke===
Zwei sich überkreuzende [[Primitive|Quads]] können auch die Illusion einer Säule hervorrufen. Diese Technik wurde häufig für die Darstellung [[Polygon]] armer Bäume verwendet. <br>
Dies ist die schnellste aber auch unschönste Methode, wenn man auf [[Vertexprogramm]]e verzichten will/muss.

=== Billboard ===
Eine andere Möglichkeit wäre noch, nur ein [[Primitive|Rechteck]] mit [[Textur]] zu zeichnen, und dann durch entsprechende Ausrichtung zum Betrachter eine Säule oder einen Stahl vorzutäuschen. Diese Ausrichtungstechnik nennt man zylindrisches [[Billboard]]ing. Diese Illusion fliegt allerdings auf, wenn man von oben auf die Säule schaut, denn je weiter von oben man auf das zylindrische [[Billboard]] schaut, desto mehr erscheint es als Linie und nicht mehr als [[Primitive|Rechteck]].

== Allgemeine Hinweise ==
Um die Effekte etwas prickelnder gestalten zu können, kann man mit [[Multitexturing]] auch mehrere Texturen auf die Oberfläche [[Blenden]].

== Grundlagen ==
*Nun die Grundlagen ([[glBegin]]), wie man Oberflächen rendert auf jeden Fall.
*Natürlich auch Texturierungsbefehle ([[glTexCoord]], [[glTexParameter]]).

== Brauchbare Artikel ==
[[Blenden]], [[Multitexturing]], [[Texture Loader]], [[Billboard]]

[[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]] [[Kategorie:Effekt]]

glPushAttrib

2008-04-12T21:26:06Z

Wilson: "gl"s bei Siehe auch hinzugefügt

= glPushAttrib, glPopAttrib =

== Name ==
'''glPushAttrib, glPopAttrib''' - legt Attribute auf bzw. holt Attribute vom [[Stack|Attributstack]].
<br>

== Delphi-Spezifikation ==
procedure '''glPushAttrib'''(''mask'': TGLbitfield);
procedure '''glPopAttrib''';

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''mask''</td>
<td>Ist ein Bitfeld das angibt, welche Attribute auf den Attributstack gelegt werden sollen. Wie man einzelne Bits im Bitfeld setzt, finden Sie unter '''Beschreibung'''.</td>
</tr>
</table>

== Beschreibung ==
'''glPushAttrib''' nimmt ein Argument, ''mask'', dass angibt, welche Gruppen von Zustandsvariablen der GL auf den Attributstack gelegt werden sollen. Die Bits des Bitfelds ''mask'' werden normalerweise durch symbolische Konstanten gesetzt. Dies geschieht, indem man die einzelnen Konstanten mittels '''or''' verknüpft.<br>
Möchte man alle speicherbaren Zustände auf den Stack legen, kann man dazu die spezielle Konstante '''GL_ALL_ATTRIB_BITS''' benutzen.

Nach der Initialisierung des Attributstacks ist selbiger leer.

'''glPopAttrib''' stellt die zuletzt auf den Attributstack abgelegten Zustandsvariablen wieder her. Die Variablen, die nicht auf den Stack gelegt wurden, werden nicht verändert.

=== Symbolische Konstanten ===
Es folgen alle akzeptierten Konstanten und die Zustände der GL die sie repräsentieren. <br>
(Die eingerückten Abschnitte bezeichnen die Attribute die auf den Stack abgelegt werden.):

'''GL_ACCUM_BUFFER_BIT'''
: Löschwert für den [[Akkumulationspuffer]]

'''GL_COLOR_BUFFER_BIT'''
: '''GL_ALPHA_TEST''' Aktivierungsbit
: Alphatest Funktionen und Referenzwerte
: '''GL_BLEND''' Aktivierungsbit
: Quell- und Zielfunktionen für [[Blenden]]
: '''GL_DITHER''' Aktivierungsbit
: '''GL_DRAW_BUFFER''' Einstellungen
: '''GL_LOGIC_OP''' Aktivierungsbit
: Funktion für logische Operationen
: Löschwerte für Farb- und Indexmodus
: Schreibmasken für Farb- und Indexmodus

'''GL_CURRENT_BIT'''
: Aktuelle RGBA Farbe
: Aktueller Farbindex
: Aktueller Normalenvektor
: Aktuelle Texturkoordinaten
: Aktuelle Rasterposition
: '''GL_CURRENT_RASTER_POSITION_VALID''' Flag
: RGBA Farbe an der aktuellen Rasterposition
: Farbindex an der aktuellen Rasterposition
: Texturkoordinaten an der aktuellen Rasterposition
: '''GL_EDGE_FLAG''' Flag

'''GL_DEPTH_BUFFER_BIT'''
: '''GL_DEPTH_TEST''' Aktivierungsbit
: Tiefentest Funktion
: Löschwert für den [[Tiefenpuffer]]
: '''GL_DEPTH_WRITEMASK''' Aktivierungsbit

'''GL_ENABLE_BIT'''
: '''GL_ALPHA_TEST''' Flag
: '''GL_AUTO_NORMAL''' Flag
: '''GL_BLEND''' Flag
: Aktivierungsbits für die nutzerdefinierten [[Clipping Plane|Clipping Planes]]
: '''GL_COLOR_MATERIAL'''
: '''GL_CULL_FACE''' Flag
: '''GL_DEPTH_TEST''' Flag
: '''GL_DITHER''' Flag
: '''GL_FOG''' Flag
: '''GL_LIGHT'''i wobei 0 <= i < '''GL_MAX_LIGHTS'''
: '''GL_LIGHTING''' Flag
: '''GL_LINE_SMOOTH''' Flag
: '''GL_LINE_STIPPLE''' Flag
: '''GL_COLOR_LOGIC_OP''' Flag
: '''GL_INDEX_LOGIC_OP''' Flag
: '''GL_MAP1'''_x wobei x ein Maptyp ist
: '''GL_MAP2'''_x wobei x ein Maptyp ist
: '''GL_NORMALIZE''' Flag
: '''GL_POINT_SMOOTH''' Flag
: '''GL_POLYGON_OFFSET_LINE''' Flag
: '''GL_POLYGON_OFFSET_FILL''' Flag
: '''GL_POLYGON_OFFSET_POINT''' Flag
: '''GL_POLYGON_SMOOTH''' Flag
: '''GL_POLYGON_STIPPLE''' Flag
: '''GL_SCISSOR_TEST''' Flag
: '''GL_STENCIL_TEST''' Flag
: '''GL_TEXTURE_1D''' Flag
: '''GL_TEXTURE_2D''' Flag
: '''GL_TEXTURE_3D''' Flag
: '''GL_TEXTURE_GEN'''_x Flags wobei x = '''S, T, R''' oder '''Q''' ist.

'''GL_EVAL_BIT'''
: '''GL_MAP1'''_x Aktivierungsbit wobei x ein Maptyp ist.
: '''GL_MAP2'''_x Aktivierungsbit wobei x ein Maptyp ist.
: 1D Gitter Endpunkte und Unterteilungen
: 2D Gitter Endpunkte und Unterteilungen
: '''GL_AUTO_NORMAL''' Aktivierungsbit

'''GL_FOG_BIT'''
: '''GL_FOG''' Aktivierungsbit
: Nebelfarbe
: Nebeldichte
: Lineare Nebelstartweite
: Lineare Nebelendweite
: Nebelindex
: '''GL_FOG_MODE''' Wert

'''GL_HINT_BIT'''
: '''GL_PERSPECTIVE_CORRECTION_HINT''' Einstellung
: '''GL_POINT_SMOOTH_HINT''' Einstellung
: '''GL_LINE_SMOOTH_HINT''' Einstellung
: '''GL_POLYGONE_SMOOTH_HINT''' Einstellung
: '''GL_FOG_HINT''' Einstellung

'''GL_LIGHTING_BIT'''
: '''GL_COLOR_MATERIAL''' Aktivierungsbit
: '''GL_COLOR_FACE_MATERIAL_FACE''' Wert
: Farbmaterialparameter, welche die aktuelle Farbe beeinflussen.
: Ambiente Szenenfarbe
: '''GL_LIGHT_MODEL_LOCAL_VIEWER''' Wert
: '''GL_LIGHT_MODEL_TWO_SIDE''' Einstellung
: '''GL_LIGHTING''' Aktivierungsbit
: Aktivierungsbits für jedes Licht
: Ambiente-, Diffuse- und Glanzlichtintensität jedes Licht
: Richtung, Position, Exponent und Streuwinkel für jedes Licht
: Konstante, lineare und quadratische Lichtabschwächungsfaktoren für jedes Licht
: Ambiente-, Diffuse-, Glanzlicht- und Strahlungfarbe für jedes Material.
: Ambiente-, Diffuse- und Glanzlichtfarbindizes für jedes Material
: Glanzexponent für jedes Material
: '''GL_SHADE_MODEL''' Einstellungen

'''GL_LINE_BIT'''
: '''GL_LINE_SMOOTH''' Flag
: '''GL_LINE_STIPPLE''' Aktivierungsbit
: Linienpunktierungsmuster und Wiederholungszähler
: Linienstärke

'''GL_LIST_BIT'''
: '''GL_LIST_BASE''' Einstellung

'''GL_PIXEL_MODE_BIT'''
: '''GL_RED_BIAS''' und '''GL_RED_SCALE''' Einstellungen
: '''GL_GREEN_BIAS''' und '''GL_GREEN_SCALE''' Werte
: '''GL_BLUE_BIAS''' und '''GL_BLUE_SCALE'''
: '''GL_ALPHA_BIAS''' und '''GL_ALPHA_SCALE'''
: '''GL_DEPTH_BIAS''' und '''GL_DEPTH_SCALE'''
: '''GL_INDEX_OFFSET''' und '''GL_INDEX_SHIFT''' Werte
: '''GL_MAP_COLOR''' und '''GL_MAP_STENCIL''' Flags
: '''GL_ZOOM_X''' und '''GL_ZOOM_Y''' Faktoren
: '''GL_READ_BUFFER''' Einstellung

'''GL_POINT_BIT'''
: '''GL_POINT_SMOOTH''' Flag
: Punktgröße

'''GL_POLYGON_BIT'''
: '''GL_CULL_FACE''' Aktivierungsbit
: '''GL_CULL_FACE_MODE''' Wert
: '''GL_FRONT_FACE''' Indikator
: '''GL_POLYGON_MODE''' Einstellung
: '''GL_POLYGON_SMOOTH''' Flag
: '''GL_POLYGON_STIPPLE''' Aktivierungsbit
: '''GL_POLYGON_OFFSET_FILL''' Flag
: '''GL_POLYGON_OFFSET_LINE''' Flag
: '''GL_POLYGON_OFFSET_POINT''' Flag
: '''GL_POLYGON_OFFSET_FACTOR'''
: '''GL_POLYGON_OFFSET_UNITS'''

'''GL_POLYGONE_STIPPLE_BIT'''
: Polygonpunktierungsbild

'''GL_SCISSOR_BIT'''
: '''GL_SCISSOR_TEST''' Flag
: Scissorbox

'''GL_STENCIL_BUFFER_BIT'''
: '''GL_STENCIL_TEST''' Aktivierungsbit
: Schablonenfunktion und Referenzwert
: Schablonen-Wertemaske
: Aktionen bei Bestehen und Durchfallen des Stenciltests und Bestehen des Tiefentests Aktionen
: Stencilpuffer Löschwert
: Stencilpuffer Schreibmaske

'''GL_TEXTURE_BIT'''
: Aktivierungsbits für die vier Texturkoordinaten
: Randfarbe für jedes Texturbild
: Verkleinerungsfunktion für jedes Texturbild
: Vergrößerungsfunktion für jedes Texturbild
: Texturkoordinaten und Wrapmodus für jedes Texturbild
: Farbe und Modus für jede Texturumgebung
: Aktivierungsbits '''GL_TEXTURE_GEN_'''x, x ist dabei '''S, T, R''' oder '''Q'''
: '''GL_TEXTURE_GEN_MODE'''-Einstellungen für '''S, T, R''' und '''Q'''
: '''glTexGen''' Ebenengleichung für '''S, T, R''' und '''Q'''
: Aktuelle gebundenen Texturen (z.B. ''GL_TEXTURE_2D_BINDING)

'''GL_TRANSFORM_BIT'''
: Koeffizienten der sechs [[Clipping Plane|Clippingplanes]]
: Aktivierungsbit für die vom Benutzer definierten Clippingplanes
: '''GL_MATRIX_MODE''' Wert
: '''GL_NORMALIZE''' Flag

'''GL_VIEWPORT_BIT'''
: Tiefenbereich (nah und fern) (Depth range)
: Sichtfeldursprung und Ausdehnung

== Hinweise ==
Nicht alle Werte können auf den Attributstack abgelegt werden. So können zum Beispiel PixelPack- und UnPack-Zustand, Rendermoduszustand sowie Selctions- und Feedback-Zustand nicht gespeichert werden.

Ein Fehler wird ausgelöst, wenn versucht wird auf einen vollen Attributstack Werte abzulegen, bzw. von einem leeren Stack Werte abzurufen. In beiden Fällen wird das Errorflag gesetzt und es werden keine Änderung an den Zuständen der GL durchgeführt.

Die Tiefe des Attributstack hängt von der Implementierung ab, muss aber mindestens 16 sein.

== Fehlermeldungen ==
'''GL_STACK_OVERFLOW''' wird generiert wenn '''glPushAttrib''' aufgerufen wird, während der Attributstack voll ist.<br>
'''GL_STACK_UNDERFLOW''' wird generiert wenn '''glPopAttrib''' aufgerufen wird, während der Attributstack leer ist.<br>
'''GL_INVALID_OPERATION''' wird generiert wenn '''glPushAttrib''' innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
[[glGet]] mit Token [[glGet#GL_ATTRIB_STACK_DEPTH|GL_ATTRIB_STACK_DEPTH]]<br>
[[glGet]] mit Token [[glGet#GL_MAX_ATTRIB_STACK_DEPTH|GL_MAX_ATTRIB_STACK_DEPTH]]

== Siehe auch ==
[[glGet]], [[glGetClipPlane]], [[glGetError]], [[glGetLight]], [[glGetMap]], [[glGetMaterial]], [[glGetPixelMap]], [[glGetPolygonStipple]], [[glGetString]], [[glGetTexEnv]], [[glGetTexGen]], [[glGetTexImage]], [[glGetTexLevelParameter]], [[glGetTexParameter]], [[glIsEnabled]]

[[Kategorie:GL|PushAttrib]]
[[Kategorie:GL1.0]]

Tutorial Framebufferobject

2008-04-12T16:34:48Z

Wilson: mehrere Fehler in Fehlerabfrage korrigiert

=GL_EXT_FRAMEBUFFER_OBJECT=
==Einleitung==
Willkommen zu meinem ersten Tutorial. Das Thema des Tutorials sind Framebufferobjekte. Diese stellen derzeit die wohl einfachste Möglichkeit für Offscreen Rendering dar. Im Gegensatz zu Pixelbuffern sind sie plattformunabhängig und bieten automatisches Mipmapping. Jedoch benötigen sie mindestens OpenGL 1.1. Außerdem unterstützen Framebufferobjekte kein AntiAliasing. In der Vergangenheit hatten auch ATI Treiber einige Probleme mit ihnen, dies dürfte aber der Vergangenheit angehören.

==Das FBO erstellen==
Zuerst einmal muss das Framebufferobjekt natürlich generiert werden. Dies läuft ähnlich wie das Erstellen einer Textur ab:
<pascal>
var
fbo: GluInt;

glGenFramebuffersEXT(1, @fbo);
</pascal>
Wie bei allem anderen auch müssen wir das Framebufferobjekt jetzt binden, damit alles, was folgt sich auf dieses Objekt bezieht:
<pascal>
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
</pascal>
Der erste Parameter von [[glBindFramebufferEXT]] ist das Ziel an das gebunden wird. Derzeit existiert aber nur GL_FRAMEBUFFER_EXT.

==Einen Depthbuffer hinzufügen==
Ein einfaches Framebufferobjekt ist noch ziemlich nutzlos. Deswegen fügen wir zuerst einmal einen der neu eingeführten Renderbuffer als Depthbuffer hinzu.
Renderbuffer sind im Prinzip Objekte, die benutzt werden wenn ein Buffer kein zugehöriges Texturformat besitzt. Dazu zählen u.a. der Stencilbuffer, der Accumulationbuffer und der Depthbuffer. Das Binden an den Accumulationbuffer wurde allerdings auf eine spätere Extension verschoben.
Wie auch beim Framebufferobjekt müssen wir einen Renderbuffer zuerst generieren und dann binden:
<pascal>
var
depthbuffer: GluInt;

glGenRenderbuffersEXT(1, @depthbuffer);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depthbuffer);
</pascal>
Derzeit hat der Renderbuffer allerdings noch keinen Speicher zugeteilt bekommen. Deswegen sagen wir OpenGL, wie wir den Renderbuffer benutzen wollen und welche Größe er haben soll:
<pascal>
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, 512, 512);
</pascal>
Mit [[glRenderbufferStorageEXT]] hat OpenGL den Speicher für den Renderbuffer, den wir als Depthbuffer nutzen, reserviert. Jetzt können wir unseren Depthbuffer zum FBO hinzufügen:
<pascal>
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT,
GL_RENDERBUFFER_EXT, depthbuffer);
</pascal>
Die letzte Anweisung sollte ziemlich einfach zu verstehen sein. Der zweite Parameter sagt einfach, als was der Renderbuffer genutzt werden soll.

==Eine Textur hinzufügen==
Um Farbinformationen in unser Framebufferobjekt schreiben zu können, fügen wir eine Textur hinzu. Bevor wir sie hinzufügen können müssen wir sie natürlich noch erstellen:
<pascal>
var
tex: GluInt;

glGenTextures(1, @tex);
glBindTextures(GL_TEXTURE_2D, tex);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA8, GL_UNSIGNED_BYTE, nil);
</pascal>
Es dürfte eigentlich nichts völlig Unverständliches da stehen. Wir erstellen die Textur, binden sie, stellen die Filtermodi ein und erzeugen im Speicher den entsprechenden Platz. Anzumerken ist aber, dass die Textur die '''gleiche Größe wie der Renderbuffer haben muss'''. Alle Größen müssen einheitlich sein. Man kann also nicht einen Renderbuffer von 512*512 und eine Textur von 256*256 erstellen und sie zusammen in einem FBO nutzen. Hinzugefügt wird sie nach dem gleichen Schema wie der Depthbuffer:
<pascal>
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, tex, 0);
</pascal>
Wie gesagt, nicht viel neues hier. Der zweite Parameter, GL_COLOR_ATTACHMENT0_EXT sagt OpenGL wo die Textur hinzugefügt werden soll (man kann mehrere hinzufügen, doch dazu später mehr). Der letzte Parameter beschreibt das Mipmaping-Level.

==Die Fehlerabfrage==
Derzeit wissen wir nicht, ob alles so geklappt hat, wie wir es wollten oder ob wir einen Fehler gemacht haben. Deswegen ist nun die Fehlerabfrage an der Reihe. Dazu gibt es die Funktion [[glCheckFramebufferStatusEXT]]. Die Fehlerabfrage lässt sich schön in so einer Prozedur verpacken:
<pascal>
procedure TForm1.CheckFBO;
var
error: GlEnum;
begin
error := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);
case error of
GL_FRAMEBUFFER_COMPLETE_EXT:
Exit;
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT:
raise Exception.Create('Incomplete attachment');
GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT_EXT:
raise Exception.Create('Missing attachment');
GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT:
raise Exception.Create('Incomplete dimensions');
GL_FRAMEBUFFER_INCOMPLETE_FORMATS_EXT:
raise Exception.Create('Incomplete formats');
GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT:
raise Exception.Create('Incomplete draw buffer');
GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT:
raise Exception.Create('Incomplete read buffer');
GL_FRAMEBUFFER_UNSUPPORTED_EXT:
raise Exception.Create('Framebufferobjects unsupported');
end;
end;
</pascal>

==Die Codeübersicht==
Zur Übersicht noch einmal der komplette Code zum erstellen eines Framebufferobjekts:
<pascal>
var
fbo: GluInt;
depthbuffer: GluInt;
tex: GluInt;

procedure TForm1.InitFBO;
begin
glGenFramebuffersEXT(1, @fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glGenRenderbuffersEXT(1, @depthbuffer);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depthbuffer);
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, 512, 512);
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, depthbuffer);
glGenTextures(1, @tex);
glBindTexture(GL_TEXTURE_2D, tex);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, nil);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
GL_TEXTURE_2D, tex, 0);
CheckFBO;
end;
</pascal>

==In die Textur rendern==
Der eigentliche Rendervorgang ist ziemlich simpel und unterscheidet sich nicht sonderlich vom normalen Rendern. Das Framebufferobjekt teilt sich alle Einstellungen mit dem eigentlichen Renderingkontext. Deswegen muss eigentlich nur das FBO gebunden und der Viewport auf die entsprechende Breite und Höhe eingestellt werden:
<pascal>
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT);
glViewPort(0, 0, 512, 512);

//ganz normal rendern – das Ergebnis landet in der Textur

glPopAttrib;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Wie gesagt, hier gibt’s nichts bemerkenswertes: Viewport speichern, umstellen, rendern, Viewport laden und mit der letzten Zeile das FBO abschalten.
Die Textur die an das Framebufferobjekt gebunden wurde, enthält das Gezeichnete und wird ganz normal mit [[glBindTexture]](GL_TEXTURE_2D, tex) benutzt.

==Mipmaps==
FBOs bieten die Möglichkeit zum automatischem Erstellen der Mipmapdaten. Dazu gibt es die Funktion [[glGenerateMipmapEXT]]. Man bindet die Textur zunächst und ruft dann die Funktion auf:
<pascal>
procedure TForm1.Render;
begin
//...
glBindTexture(GL_TEXTURE_2D, tex);
glGenerateMipmapEXT(GL_TEXTURE_2D);

//Textur danach ganz normal benutzen

end;
</pascal>
Wenn man hingegen einen der Mipmap Filter verwendet muss der Befehl [[glGenerateMipmapEXT]] bevor der Status des FBOs überprüft oder versucht wird in die Textur zu rendern aufgerufen werden. Ein Beispiel wäre folgender Code in der Initialisierung des Framebufferobjektes:
<pascal>
var
fbo: GluInt;
depthbuffer: GluInt;
tex: GluInt;

glGenTextures(1, @tex);
glBindTexture(GL_TEXTURE_2D, tex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, nil);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_MIPMAP_LINEAR);
glGenerateMipmapEXT(GL_TEXTURE_2D);
</pascal>

==Und wieder aufräumen==
Beim Beenden unseres Programms soll das alles natürlich auch wieder gelöscht werden:
<pascal>
glDeleteFramebuffersEXT(1, @fbo);
glDeleteRenderbuffersEXT(1, @depthbuffer);
glDeleteTextures(1, @tex);
</pascal>
Ich denke das Ganze ist selbsterklärend.

==Mehrere Texturen in einem FBO==
Wie vorhin erwähnt gibt es auch die Möglichkeit mehrere Texturen an ein Framebufferobjekt zu binden. Dazu schauen wir uns nochmal den Befehl zum hinzufügen einer Textur an:
<pascal>
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, tex, 0);
</pascal>
Der zweite Parameter sagt OpenGL an welches COLOR_ATTACHMENT die Textur zugefügt wird. Die derzeitigen Spezifikationen erlauben bis zu 16 COLOR_ATTACHMENTS (GL_COLOR_ATTACHMENT0_EXT bis GL_COLOR_ATTACHMENT15_EXT). Allerdings ist die wirkliche Anzahl von möglichen COLOR_ATTACHMENTS durch die Grafikkarte und deren Treiber begrenzt. Die maximale Anzahl kann durch folgenden Code ermittelt werden:
<pascal>
var
maxbuffers: GluInt;

glGetIntegeri(GL_MAX_COLOR_ATTACHMENTS_EXT, @maxbuffers);
</pascal>
Eine zweite, wie oben beschrieben erstellte Textur, kann also mit folgendem Code zum Framebufferobjekt hinzugefügt werden:
<pascal>
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, tex2, 0);
</pascal>

==In die zweite Textur rendern==
Mit dem Befehl [[glDrawBuffer]](GL_COLOR_ATTACHMENT'''n'''_EXT) lässt sich einstellen, in welchen Buffer man rendern möchte (wobei '''n''' den Buffer repräsentiert, also 0, 1, usw.). Standartmäßig ist GL_COLOR_ATTACHMENT0_EXT aktiviert (logisch, sonst hätten wir vorhin nicht viel gesehen, oder ;-) ). Soll also nur in diesen gerendert werden, ist keine weitere Anweisung nötig. Ansonsten sieht der Code folgendermaßen aus:
<pascal>
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

//in die Textur von GL_COLOR_ATTACHMENT0_EXT rendern

glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);

//in die Textur von GL_COLOR_ATTACHMENT1_EXT rendern

glPopAttrib;
glBindFrameBuffer(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Diesmal werden Viewport und Colorbuffer gespeichert, da Veränderungen immer das Framebufferobjekt und den eigentlichen Renderingkontext betreffen. Veränderungen am RC sind aber nicht gewollt, deswegen wird beides gespeichert und später wieder geladen.
Wie beim normalen Renderpass ist der Colorbuffer bereits mit den Daten die in die erste Textur geschrieben werden gefüllt. Deswegen leert man diesen normalerweise vor dem Rendern in die zweite Textur mithilfe von [[glClear]]:
<pascal>
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

//in die Textur von GL_COLOR_ATTACHMENT0_EXT rendern

glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//in die Textur von GL_COLOR_ATTACHMENT1_EXT rendern

glPopAttrib;
glBindFrameBuffer(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Es ist im übrigen schneller ein FBO für mehrere Texturen zu nutzen als mehrere FBOs zu erstellen und zwischen ihnen zu wechseln.

==Multiple Render Targets==
Mithilfe des Befehls [[glDrawBuffers]] kann in einem FBO gleichzeitig in mehrere Texturen gerendert werden. Die Namen der GL_COLOR_ATTACHMENTS werden in einem Array abgelegt und mit dem Befehl übergeben:
<pascal>
var
buffers: Array[0..1] of GlEnum;

buffers[0] := GL_COLOR_ATTACHMENT0_EXT;
buffers[1] := GL_COLOR_ATTACHMENT1_EXT;
//...
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

glDrawBuffers(2, @buffers);
//normal rendern

glPopAttrib;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Die Hardware und der Treiber legen die Grenze für die Anzahl von Texturen in die gleichzeitig gerendert werden kann. Der Wert kann mit folgendem Code erhalten werden:
<pascal>
var
maxbuffers: GluInt;

glGetIntegeri(GL_MAX_DRAW_BUFFERS, @maxbuffers);
</pascal>

==MRT und GLSL==
Solange man mindestens für die OpenGL Version 2.0 (bzw. GLSL Version 1.10) schreibt, kann man mithilfe von GLSL gleichzeitig unterschiedliche Dinge in zwei Texturen rendern. Dazu benutzt man in GLSL anstelle von gl_FragColor den Array gl_FragData[]. Als Beispiel rendern wir ein rotes und ein grünes Viereck:
<pascal>
var
buffers: Array[0..1] of GlEnum;
//...
buffers[0] := GL_COLOR_ATTACHMENT0_EXT;
buffers[1] := GL_COLOR_ATTACHMENT1_EXT;
//...
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

glDrawBuffers(2, @buffers);
//Viereck zeichnen

glPopAttrib;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Der aufmerksame Leser merkts - der Delphi Code hat sich eigentlich nicht verändert :-). Also auf zu den Shadern. Der Vertexshader enthält nur das Nötigste:
<glsl>
void main(void)
{
gl_Position = ftransform();
}
</glsl>
Und der Fragmentshader sieht folgendermaßen aus:
<glsl>
void main(void)
{
gl_FragData[0] = vec4( 1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4( 0.0, 1.0, 0.0, 1.0);
}
</glsl>
Und siehe da – die Textur die zu GL_COLOR_ATTACHMENT0_EXT gehört bekommt die Daten für ein rotes Quad und die zweite Textur die Daten für ein grünes Quad.
Eine Sache bleibt aber noch zu erwähnen: Es ist die Reihenfolge in der die Werte der COLOR_ATTACHMENTS übergeben werden, die bestimmt was gl_FragData[0] und was gl_FragData[1] ist. Wenn wir also geschrieben hätten
<pascal>
var
buffers: Array[0..1] of GlEnum;

buffers[0] := GL_COLOR_ATTACHMENT1_EXT;
buffers[1] := GL_COLOR_ATTACHMENT0_EXT;
</pascal>
dann würde gl_FragData[0] GL_COLOR_ATTACHMENT1_EXT beeinflussen und gl_FragData[1] GL_COLOR_ATTACHMENT0_EXT.

==Und fertig!==
So! Geschafft. Schlussendlich bleibt zu sagen das Framebufferobjekte sehr nützliche Helfer sind, die sich relativ leicht handhaben lassen.
Zum Abschluss möchte ich euch nochmal daran erinnern, dass dies mein erstes Tutorial war, haltet euch also ordentlich ran mit Feedback ;-)

Cya,
Deathball

==Quellen==
* http://www.gamedev.net/reference/articles/article2331.asp
* http://www.gamedev.net/reference/articles/article2333.asp

==Weiterführende Links==
* http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt
* http://http.download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenGL_FrameBuffer_Object.pdf

{{TUTORIAL_NAVIGATION|[[Tutorial_Pixelbuffer]]|-}}

[[Kategorie:Tutorial|Framebufferobject]]

Tutorial Framebufferobject

2008-04-12T16:23:13Z

Wilson:

=GL_EXT_FRAMEBUFFER_OBJECT=
==Einleitung==
Willkommen zu meinem ersten Tutorial. Das Thema des Tutorials sind Framebufferobjekte. Diese stellen derzeit die wohl einfachste Möglichkeit für Offscreen Rendering dar. Im Gegensatz zu Pixelbuffern sind sie plattformunabhängig und bieten automatisches Mipmapping. Jedoch benötigen sie mindestens OpenGL 1.1. Außerdem unterstützen Framebufferobjekte kein AntiAliasing. In der Vergangenheit hatten auch ATI Treiber einige Probleme mit ihnen, dies dürfte aber der Vergangenheit angehören.

==Das FBO erstellen==
Zuerst einmal muss das Framebufferobjekt natürlich generiert werden. Dies läuft ähnlich wie das Erstellen einer Textur ab:
<pascal>
var
fbo: GluInt;

glGenFramebuffersEXT(1, @fbo);
</pascal>
Wie bei allem anderen auch müssen wir das Framebufferobjekt jetzt binden, damit alles, was folgt sich auf dieses Objekt bezieht:
<pascal>
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
</pascal>
Der erste Parameter von [[glBindFramebufferEXT]] ist das Ziel an das gebunden wird. Derzeit existiert aber nur GL_FRAMEBUFFER_EXT.

==Einen Depthbuffer hinzufügen==
Ein einfaches Framebufferobjekt ist noch ziemlich nutzlos. Deswegen fügen wir zuerst einmal einen der neu eingeführten Renderbuffer als Depthbuffer hinzu.
Renderbuffer sind im Prinzip Objekte, die benutzt werden wenn ein Buffer kein zugehöriges Texturformat besitzt. Dazu zählen u.a. der Stencilbuffer, der Accumulationbuffer und der Depthbuffer. Das Binden an den Accumulationbuffer wurde allerdings auf eine spätere Extension verschoben.
Wie auch beim Framebufferobjekt müssen wir einen Renderbuffer zuerst generieren und dann binden:
<pascal>
var
depthbuffer: GluInt;

glGenRenderbuffersEXT(1, @depthbuffer);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depthbuffer);
</pascal>
Derzeit hat der Renderbuffer allerdings noch keinen Speicher zugeteilt bekommen. Deswegen sagen wir OpenGL, wie wir den Renderbuffer benutzen wollen und welche Größe er haben soll:
<pascal>
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, 512, 512);
</pascal>
Mit [[glRenderbufferStorageEXT]] hat OpenGL den Speicher für den Renderbuffer, den wir als Depthbuffer nutzen, reserviert. Jetzt können wir unseren Depthbuffer zum FBO hinzufügen:
<pascal>
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT,
GL_RENDERBUFFER_EXT, depthbuffer);
</pascal>
Die letzte Anweisung sollte ziemlich einfach zu verstehen sein. Der zweite Parameter sagt einfach, als was der Renderbuffer genutzt werden soll.

==Eine Textur hinzufügen==
Um Farbinformationen in unser Framebufferobjekt schreiben zu können, fügen wir eine Textur hinzu. Bevor wir sie hinzufügen können müssen wir sie natürlich noch erstellen:
<pascal>
var
tex: GluInt;

glGenTextures(1, @tex);
glBindTextures(GL_TEXTURE_2D, tex);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA8, GL_UNSIGNED_BYTE, nil);
</pascal>
Es dürfte eigentlich nichts völlig Unverständliches da stehen. Wir erstellen die Textur, binden sie, stellen die Filtermodi ein und erzeugen im Speicher den entsprechenden Platz. Anzumerken ist aber, dass die Textur die '''gleiche Größe wie der Renderbuffer haben muss'''. Alle Größen müssen einheitlich sein. Man kann also nicht einen Renderbuffer von 512*512 und eine Textur von 256*256 erstellen und sie zusammen in einem FBO nutzen. Hinzugefügt wird sie nach dem gleichen Schema wie der Depthbuffer:
<pascal>
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, tex, 0);
</pascal>
Wie gesagt, nicht viel neues hier. Der zweite Parameter, GL_COLOR_ATTACHMENT0_EXT sagt OpenGL wo die Textur hinzugefügt werden soll (man kann mehrere hinzufügen, doch dazu später mehr). Der letzte Parameter beschreibt das Mipmaping-Level.

==Die Fehlerabfrage==
Derzeit wissen wir nicht, ob alles so geklappt hat, wie wir es wollten oder ob wir einen Fehler gemacht haben. Deswegen ist nun die Fehlerabfrage an der Reihe. Dazu gibt es die Funktion [[glCheckFramebufferStatusEXT]]. Die Fehlerabfrage lässt sich schön in so einer Prozedur verpacken:
<pascal>
procedure TForm1.CheckFBO;
var
error: GlEnum;
begin
error := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT);
case s of:
GL_FRAMEBUFFER_COMPLETE_EXT:
Exit;
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT:
raise Exception.Create('Incomplete attachment');
GL_FRAMEBUFFER_INCOMOPLETE_MISSING_ATTACHMENT_EXT:
raise Exception.Create('Missing attachment');
GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT:
raise Exception.Create('Incomplete dimensions');
GL_FRAMEBUFFER_INCOMPLETE_FORMATS_EXT:
raise Exception.Create('Incomplete formats');
GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER_EXT:
raise Exception.Create('Incomplete draw buffer');
GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT:
raise Exception.Create('Incomplete read buffer');
GL_FRAMEBUFFER_UNSUPPORTED_EXT:
raise Exception.Create('Framebufferobjects unsupported');
end;
end;
</pascal>

==Die Codeübersicht==
Zur Übersicht noch einmal der komplette Code zum erstellen eines Framebufferobjekts:
<pascal>
var
fbo: GluInt;
depthbuffer: GluInt;
tex: GluInt;

procedure TForm1.InitFBO;
begin
glGenFramebuffersEXT(1, @fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glGenRenderbuffersEXT(1, @depthbuffer);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, depthbuffer);
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT, 512, 512);
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, depthbuffer);
glGenTextures(1, @tex);
glBindTexture(GL_TEXTURE_2D, tex);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, nil);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
GL_TEXTURE_2D, tex, 0);
CheckFBO;
end;
</pascal>

==In die Textur rendern==
Der eigentliche Rendervorgang ist ziemlich simpel und unterscheidet sich nicht sonderlich vom normalen Rendern. Das Framebufferobjekt teilt sich alle Einstellungen mit dem eigentlichen Renderingkontext. Deswegen muss eigentlich nur das FBO gebunden und der Viewport auf die entsprechende Breite und Höhe eingestellt werden:
<pascal>
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT);
glViewPort(0, 0, 512, 512);

//ganz normal rendern – das Ergebnis landet in der Textur

glPopAttrib;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Wie gesagt, hier gibt’s nichts bemerkenswertes: Viewport speichern, umstellen, rendern, Viewport laden und mit der letzten Zeile das FBO abschalten.
Die Textur die an das Framebufferobjekt gebunden wurde, enthält das Gezeichnete und wird ganz normal mit [[glBindTexture]](GL_TEXTURE_2D, tex) benutzt.

==Mipmaps==
FBOs bieten die Möglichkeit zum automatischem Erstellen der Mipmapdaten. Dazu gibt es die Funktion [[glGenerateMipmapEXT]]. Man bindet die Textur zunächst und ruft dann die Funktion auf:
<pascal>
procedure TForm1.Render;
begin
//...
glBindTexture(GL_TEXTURE_2D, tex);
glGenerateMipmapEXT(GL_TEXTURE_2D);

//Textur danach ganz normal benutzen

end;
</pascal>
Wenn man hingegen einen der Mipmap Filter verwendet muss der Befehl [[glGenerateMipmapEXT]] bevor der Status des FBOs überprüft oder versucht wird in die Textur zu rendern aufgerufen werden. Ein Beispiel wäre folgender Code in der Initialisierung des Framebufferobjektes:
<pascal>
var
fbo: GluInt;
depthbuffer: GluInt;
tex: GluInt;

glGenTextures(1, @tex);
glBindTexture(GL_TEXTURE_2D, tex);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, nil);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_MIPMAP_LINEAR);
glGenerateMipmapEXT(GL_TEXTURE_2D);
</pascal>

==Und wieder aufräumen==
Beim Beenden unseres Programms soll das alles natürlich auch wieder gelöscht werden:
<pascal>
glDeleteFramebuffersEXT(1, @fbo);
glDeleteRenderbuffersEXT(1, @depthbuffer);
glDeleteTextures(1, @tex);
</pascal>
Ich denke das Ganze ist selbsterklärend.

==Mehrere Texturen in einem FBO==
Wie vorhin erwähnt gibt es auch die Möglichkeit mehrere Texturen an ein Framebufferobjekt zu binden. Dazu schauen wir uns nochmal den Befehl zum hinzufügen einer Textur an:
<pascal>
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, tex, 0);
</pascal>
Der zweite Parameter sagt OpenGL an welches COLOR_ATTACHMENT die Textur zugefügt wird. Die derzeitigen Spezifikationen erlauben bis zu 16 COLOR_ATTACHMENTS (GL_COLOR_ATTACHMENT0_EXT bis GL_COLOR_ATTACHMENT15_EXT). Allerdings ist die wirkliche Anzahl von möglichen COLOR_ATTACHMENTS durch die Grafikkarte und deren Treiber begrenzt. Die maximale Anzahl kann durch folgenden Code ermittelt werden:
<pascal>
var
maxbuffers: GluInt;

glGetIntegeri(GL_MAX_COLOR_ATTACHMENTS_EXT, @maxbuffers);
</pascal>
Eine zweite, wie oben beschrieben erstellte Textur, kann also mit folgendem Code zum Framebufferobjekt hinzugefügt werden:
<pascal>
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, tex2, 0);
</pascal>

==In die zweite Textur rendern==
Mit dem Befehl [[glDrawBuffer]](GL_COLOR_ATTACHMENT'''n'''_EXT) lässt sich einstellen, in welchen Buffer man rendern möchte (wobei '''n''' den Buffer repräsentiert, also 0, 1, usw.). Standartmäßig ist GL_COLOR_ATTACHMENT0_EXT aktiviert (logisch, sonst hätten wir vorhin nicht viel gesehen, oder ;-) ). Soll also nur in diesen gerendert werden, ist keine weitere Anweisung nötig. Ansonsten sieht der Code folgendermaßen aus:
<pascal>
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

//in die Textur von GL_COLOR_ATTACHMENT0_EXT rendern

glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);

//in die Textur von GL_COLOR_ATTACHMENT1_EXT rendern

glPopAttrib;
glBindFrameBuffer(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Diesmal werden Viewport und Colorbuffer gespeichert, da Veränderungen immer das Framebufferobjekt und den eigentlichen Renderingkontext betreffen. Veränderungen am RC sind aber nicht gewollt, deswegen wird beides gespeichert und später wieder geladen.
Wie beim normalen Renderpass ist der Colorbuffer bereits mit den Daten die in die erste Textur geschrieben werden gefüllt. Deswegen leert man diesen normalerweise vor dem Rendern in die zweite Textur mithilfe von [[glClear]]:
<pascal>
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

//in die Textur von GL_COLOR_ATTACHMENT0_EXT rendern

glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//in die Textur von GL_COLOR_ATTACHMENT1_EXT rendern

glPopAttrib;
glBindFrameBuffer(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Es ist im übrigen schneller ein FBO für mehrere Texturen zu nutzen als mehrere FBOs zu erstellen und zwischen ihnen zu wechseln.

==Multiple Render Targets==
Mithilfe des Befehls [[glDrawBuffers]] kann in einem FBO gleichzeitig in mehrere Texturen gerendert werden. Die Namen der GL_COLOR_ATTACHMENTS werden in einem Array abgelegt und mit dem Befehl übergeben:
<pascal>
var
buffers: Array[0..1] of GlEnum;

buffers[0] := GL_COLOR_ATTACHMENT0_EXT;
buffers[1] := GL_COLOR_ATTACHMENT1_EXT;
//...
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

glDrawBuffers(2, @buffers);
//normal rendern

glPopAttrib;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Die Hardware und der Treiber legen die Grenze für die Anzahl von Texturen in die gleichzeitig gerendert werden kann. Der Wert kann mit folgendem Code erhalten werden:
<pascal>
var
maxbuffers: GluInt;

glGetIntegeri(GL_MAX_DRAW_BUFFERS, @maxbuffers);
</pascal>

==MRT und GLSL==
Solange man mindestens für die OpenGL Version 2.0 (bzw. GLSL Version 1.10) schreibt, kann man mithilfe von GLSL gleichzeitig unterschiedliche Dinge in zwei Texturen rendern. Dazu benutzt man in GLSL anstelle von gl_FragColor den Array gl_FragData[]. Als Beispiel rendern wir ein rotes und ein grünes Viereck:
<pascal>
var
buffers: Array[0..1] of GlEnum;
//...
buffers[0] := GL_COLOR_ATTACHMENT0_EXT;
buffers[1] := GL_COLOR_ATTACHMENT1_EXT;
//...
glBindFramebuffer(GL_FRAMEBUFFER_EXT, fbo);
glPushAttrib(GL_VIEWPORT_BIT or GL_COLOR_BUFFER_BIT);
glViewPort(0, 0, 512, 512);

glDrawBuffers(2, @buffers);
//Viereck zeichnen

glPopAttrib;
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
</pascal>
Der aufmerksame Leser merkts - der Delphi Code hat sich eigentlich nicht verändert :-). Also auf zu den Shadern. Der Vertexshader enthält nur das Nötigste:
<glsl>
void main(void)
{
gl_Position = ftransform();
}
</glsl>
Und der Fragmentshader sieht folgendermaßen aus:
<glsl>
void main(void)
{
gl_FragData[0] = vec4( 1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4( 0.0, 1.0, 0.0, 1.0);
}
</glsl>
Und siehe da – die Textur die zu GL_COLOR_ATTACHMENT0_EXT gehört bekommt die Daten für ein rotes Quad und die zweite Textur die Daten für ein grünes Quad.
Eine Sache bleibt aber noch zu erwähnen: Es ist die Reihenfolge in der die Werte der COLOR_ATTACHMENTS übergeben werden, die bestimmt was gl_FragData[0] und was gl_FragData[1] ist. Wenn wir also geschrieben hätten
<pascal>
var
buffers: Array[0..1] of GlEnum;

buffers[0] := GL_COLOR_ATTACHMENT1_EXT;
buffers[1] := GL_COLOR_ATTACHMENT0_EXT;
</pascal>
dann würde gl_FragData[0] GL_COLOR_ATTACHMENT1_EXT beeinflussen und gl_FragData[1] GL_COLOR_ATTACHMENT0_EXT.

==Und fertig!==
So! Geschafft. Schlussendlich bleibt zu sagen das Framebufferobjekte sehr nützliche Helfer sind, die sich relativ leicht handhaben lassen.
Zum Abschluss möchte ich euch nochmal daran erinnern, dass dies mein erstes Tutorial war, haltet euch also ordentlich ran mit Feedback ;-)

Cya,
Deathball

==Quellen==
* http://www.gamedev.net/reference/articles/article2331.asp
* http://www.gamedev.net/reference/articles/article2333.asp

==Weiterführende Links==
* http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt
* http://http.download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenGL_FrameBuffer_Object.pdf

{{TUTORIAL_NAVIGATION|[[Tutorial_Pixelbuffer]]|-}}

[[Kategorie:Tutorial|Framebufferobject]]

glBegin

2008-03-10T14:40:06Z

Wilson:

{{Excellent}}
= glBegin, glEnd =

== Name ==
'''glBegin, glEnd''' - Umschließen die [[Eckpunkt|Eckpunkte (Vertices)]] einer [[Primitive|Primitiven]], oder eine Gruppe gleicher [[Primitiv]]en.

== Delphi-Spezifikation ==
procedure '''glBegin'''(''mode'' : GLEnum);
procedure '''glEnd''';

== Parameter ==
{| border="1" rules="all"
! ''mode''
| Bestimmt die [[Primitive]] bzw. Gruppe von [[Primitive|Primitiven]] die aus den von '''glBegin''' und '''glEnd''' umschlossenen [[Eckpunkt|Eckpunkten (Vertices)]] erstellt werden.
Erlaubt sind die folgendenden zehn symbolischen Konstanten:
'''GL_POINTS''', '''GL_LINES''', '''GL_LINE_STRIP''', '''GL_LINE_LOOP''', '''GL_TRIANGLES''', '''GL_TRIANGLE_STRIP''', '''GL_TRIANGLE_FAN''', '''GL_QUADS''', '''GL_QUAD_STRIP''', und '''GL_POLYGON'''.
|}

== Beschreibung ==
'''glBegin''' und '''glEnd''' umschließen eine Liste von [[Eckpunkt|Eckpunkten (Vertices)]] die eine [[Primitive]] oder Gruppe von [[Primitive|Primitiven]] darstellt. '''glBegin''' erhält ein einzelnes Argument (''mode''), das angibt, auf welche Art und Weise die [[Eckpunkt|Eckpunkte (Vertices)]] interpretiert werden.

Unter der Annahme ''n'' sei ein Integerwert der bei Eins beginnt und ''N'' als Integerwert der die Gesamtanzahl der übergebenen Eckpunkte angibt, ergeben sich folgende Interpretationen :

{|{{Prettytable_B1}}
!mode
!Einschätzung
!Beschreibung
|-
|'''GL_POINTS'''
|align="center"|langsam
|[[Bild:Glbegin_points.jpg|350px|thumb|right]]
Behandelt jeden Eckpunkt als einzelnen Punkt. Eckpunkt ''n'' definiert Punkt ''n'', und ''N'' Punkte werden gerendert.
|-
|'''GL_LINES'''
|align="center"|mittel
|[[Bild:Glbegin_lines.jpg|350px|thumb|right]]
Behandelt jedes Eckpunkt-Paar als unabhängigen Linienabschnitt. Eckpunkte 2*''n''-1 und 2*''n'' beschreiben Linie n. N/2 Linien werden gerendert.
|-
|'''GL_LINE_STRIP'''
|align="center"|schnell
|[[Bild:Glbegin_linestrip.jpg|350px|thumb|right]]
Rendert eine Gruppe von miteinander verbundenen Liniensegmenten, beginnend beim ersten Eckpunkt bis zum letzten. Eckpunkte ''n'' und ''n+1'' beschreiben dabei Linie ''n''. ''N-1'' Linien werden gerendert.
|-
|'''GL_LINE_LOOP'''
|align="center"|sehr schnell
|[[Bild:Glbegin_lineloop.jpg|350px|thumb|right]]
Rendert eine miteinander verbundene Gruppe von Linienabschnitten, beginnend beim ersten Eckpunkt und endend beim letzten, und dann wieder abschließend zurück zum ersten. Eckpunkte ''n'' und ''n+1'' definieren Linie ''n''. Die letzte Linie wird jedoch durch die Eckpunkte ''N'' und 1 definiert. ''N'' Linien werden gerendert.
|-
|'''GL_TRIANGLES'''
|align="center"|schnell
|[[Bild:Glbegin_triangles.jpg|350px|thumb|right]]
Behandelt jedes Eckpunkt-Trio als unabhängiges Dreieck. Eckpunkte 3*''n''-2, 3*''n''-1 und 3*''n'' beschreiben Dreieck ''n''. ''N''/3 Dreiecke werden gerendert.

'''Eigenschaften''':
* Alle Dreiecke bestehen aus jeweils 3 Vertices, die ausschließlich nur zu diesem Dreieck gehören.
|-
|'''GL_TRIANGLE_STRIP'''
|align="center"|am schnellsten
|[[Bild:Glbegin_trianglestrip.jpg|350px|thumb|right]]
Rendert eine verbundene Gruppe von Dreiecken. Ein Dreieck wird für jeden Eckpunkt der nach den beiden ersten Eckpunkten definiert wird gerendert. Für ein ungerades ''n'' definieren die Eckpunkte ''n'', ''n''+1 und ''n''+2 Dreieck ''n'', für gerade ''n''s definieren die Eckpunkte ''n''+1, ''n'' und ''n''+2 ein Dreieck. (Man beachte, dass die Reihenfolge bei geraden ''n'' impliziet geändert wird um entgegen der Uhrzeigerrichtung zu rendern. Siehe auch [[glFrontFace]])

''N''-2 Dreiecke werden gerendert.

'''Eigenschaften''':
* Nacheinander erstellte Dreiecke haben eine gemeinsame Kante.
* Nacheinander erstellte Dreiecke benutzen 2 gemeinsame Vertices.
|-
|'''GL_TRIANGLE_FAN'''
|align="center"|schnell
|[[Bild:Glbegin_trianglefan.jpg|350px|thumb|right]]
Rendert eine verbundene Gruppe von Dreiecken. Ein Dreieck wird für jeden Eckpunkt gerendert der nach den ersten beiden definiert wird. Eckpunkte 1, ''n''+1 und ''n''+2 definieren Dreieck ''n''. ''N''-2 Dreiecke werden gerendert.

'''Eigenschaften''':
* Alle Dreiecke haben mindestens einen gemeinsamen Punkt (Vertex1).
* Nacheinander erstellte Dreiecke haben eine gemeinsame Kante.
* Nacheinander erstellte Dreiecke benutzen 2 gemeinsame Vertices.
|-
|'''GL_QUADS'''
|align="center"|schnell
|[[Bild:Glbegin_quads.jpg|350px|thumb|right]]
Behandelt jeweils vier Eckpunkte als unabhängiges Viereck. Eckpunkte 4*''n''-3, 4*''n''-2, 4*''n''-1 und 4*''n'' beschreiben Viereck ''n''. ''N''/4 Vierecke werden gerendert.

'''Eigenschaften''':
* Alle Vierecke bestehen aus jeweils 4 Vertices, die ausschließlich nur zu diesem Viereck gehören.
|-
|'''GL_QUAD_STRIP'''
|align="center"|sehr schnell
|[[Bild:Glbegin_quadstrip.jpg|350px|thumb|right]]
Rendert eine verbundene Gruppe von Vierecken. Ein Viereck wird für jedes nach den ersten beiden Eckpunkten übergebene Eckpunktepaar gerendert. Eckpunkte 2*''n''-1, 2*''n'', 2*''n''+2 und 2*''n''+1 beschreiben Viereck ''n''. ''N''/2-1 Vierecke werden gerendert. Es gilt allerdings zu beachten, dass die Reihenfolge der Eckpunkte, die genutzt werden, um Vierecke aus einem Streifen zu generieren, unterschiedlich ggü. der unabhängigen Konstruktion sind.

'''Eigenschaften''':
* Nacheinander erstellte Vierecke haben eine gemeinsame Kante.
* Nacheinander erstellte Vierecke benutzen 2 gemeinsame Vertices.
|-
|'''GL_POLYGON'''
|align="center"|(langsam)
|[[Bild:Glbegin_polygon.jpg|350px|thumb|right]]
Rendert eine einzelnes, [[konvex|konvexes]] Polygon (=Vieleck). Eckpunkte 1 bis ''N'' definieren dieses Polygon.

'''Hinweis'''

GL_POLYGON scheint für Anfänger meist die "beste Lösung" zu sein, denn man kann alle möglichen (konvexen) Polygone erzeugen. Dies ist soweit richtig, allerdings ist GL_POLYGON um ein vielfaches langsamer als GL_TRIANGLES! Dies hat die folgenden Gründe: <br>
1. sind moderne Grafikkarten auf die Darstellung von Dreiecken optimiert und <br>
2. müssen die Polygone bevor sie von den Grafikkarten verwendet werden können, erst in Dreiecke zerlegt werden (siehe [[Triangulation]]). <br>
Vorallem der letzte Punkt sorgt für niedrige Frameraten im Vergleich zu dreiecksbasierten Strukturen.<br>
''Die OpenGL-Spezifikiation erlaubt es jedoch GL_POLYGON annähernd gleich zu behandeln wie GL_TRIANGLE_FAN (die Ausnahme bildet der Wireframe-Modus mit [[glPolygonMode]]), was auch von vielen Grafikkarten in dieser Form umgesetzt wird. Ist dies der Fall, so fallen alle Vor- und Nachteile gegenüber GL_TRIANGLE_FAN weg.''
|-
|}

Nur eine Untergruppe von GL Befehlen kann zwischen '''glBegin''' und '''glEnd''' genutzt werden. Die Befehle sind [[glVertex]], [[glColor]], [[glIndex]], [[glNormal]], [[glTexCoord]], [[glEvalCoord]], [[glEvalPoint]], [[glArrayElement]], [[glMaterial]] und [[glEdgeFlag]]. Außerdem ist es erlaubt [[glCallList]] oder [[glCallLists]] zu nutzen, um [[Displaylisten]] auszuführen, die nur oben erwähnte Kommandos enthalten. Sollte ein nicht erwähnter GL Befehl zwischen '''glBegin''' und '''glEnd''' ausgeführt werden, dann wird das Fehlerflag gesetzt und der Befehl ignoriert.

Unabhängig des für ''mode'' übergebenen Wertes gibt es '''keine''' Begrenzung für die Anzahl der übergebenen Eckpunkte die zwischen '''glBegin''' und '''glEnd''' definiert werden. Linien, Dreiecke, Vierecke und Polygone die nicht genügendend beschrieben wurden, werden nicht gerendert.
Ungenügende Beschreibung bedeutet entweder, dass zu wenige Eckpunkte angegeben wurden, um eine einzelne [[Primitive]] zu beschreiben, oder ein inkorrektes Vielfaches an Eckpunkten übergeben wurde. Nicht komplette Primitiven werden ignoriert; der Rest wird gerendet.

Das Minimum an zu spezifizierenden Eckpunkten für jede Primitive ist wie folgt :
*1 für einen Punkt
*2 für eine Linie
*3 für ein Dreieck
*4 für ein Viereck und
*3 für ein Polygon.
Modi die ein festgelegtes Vielfaches an Eckpunkten brauchen sind '''GL_LINES''' (2), '''GL_TRIANGLES''' (3), '''GL_QUADS''' (4), und '''GL_QUAD_STRIP''' (2). ''(D.h. wenn man bei GL_TRIANGLES 8 Vertices angibt (kein Vielfaches von 3), werden nur die ersten 6 bearbeitet. Die restlichen 2 ergeben kein Dreieck und werden deshalb verworfen.)''

Wenn Flächen gemeinsame Punkte haben (z.B. bei '''GL_TRIANGLE_FAN''') ist es nicht möglich die Eigenschaften dieser Vertices für jede Fläche individuell zu bestimmen. Wenn dies nötig sein sollte, müssen die entsprechenden Flächen aus individuellen Vertices zusammengestellt werden.

== Fehlermeldungen ==
'''GL_INVALID_ENUM''' wird ausgelöst wenn ''mode'' einen ungültigen Wert besitzt.

'''GL_INVALID_OPERATION''' wird ausgelöst, wenn zwischen '''glBegin''' und dem zugehörigen '''glEnd''' ein weiteres '''glBegin''' aufgerufen wird.

'''GL_INVALID_OPERATION''' wird ausgelöst, wenn '''glEnd''' ohne ein vorhergehendes '''glBegin''' aufgerufen wird.

'''GL_INVALID_OPERATION''' wird aufgerufen, wenn ein anderer Befehl als [[glVertex]], [[glColor]], [[glIndex]], [[glNormal]], [[glTexCoord]], [[glEvalCoord]], [[glEvalPoint]], [[glArrayElement]], [[glMaterial]], [[glEdgeFlag]], [[glCallList]] oder [[glCallLists]] zwischen '''glBegin''' und dem zugehörigen '''glEnd''' aufgerufen wird.

Ein Aufruf von [[glEnableClientState]], [[glDisableClientState]], [[glPushClientAttrib]], [[glPopClientAttrib]], [[glEdgeFlagPointer]], [[glTexCoordPointer]], [[glColorPointer]], [[glIndexPointer]], [[glNormalPointer]], [[glVertexPointer]], [[glInterleavedArrays]] oder [[glPixelStore]] nach einem Aufruf von '''glBegin''' und dem zugehörigen '''glEnd''' ist nicht erlaubt, aber je nach Implementation wird möglicherweise kein Fehler ausgelöst.

==Beispiele==
{|{{Prettytable_B1}} width="100%"
!width="60%"|Code
!Ausgabe
|-
|
<pascal>glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(0,0,1);
glEnd;</pascal>
|[[Bild:GlBegin_Bsp1.jpg|center]]
|}

Zwischen glBegin und glEnd können natürlich auch "nicht OpenGL"-Befehle stehen was man dazu nutzen kann komplexere Gebilde direkt mit einer Schleife zeichnen zu lassen:

{|{{Prettytable_B1}} width="100%"
!width="60%"|Code
!Ausgabe
|-
|
<pascal>
glBegin(GL_LINE_STRIP);
f := 0.0;
for i:=0 to 20 do
begin
glVertex3f(cos(f),sin(f),0);
f := f + (2*Pi/20);
end;
glEnd;</pascal>
|[[Bild:GlBegin_Bsp2.jpg|center]]
|}

== Siehe auch ==
[[glArrayElement]], [[glCallList]], [[glCallLists]], [[glColor]], [[glEdgeFlag]], [[glEvalCoord]], [[glEvalPoint]], [[glIndex]], [[glMaterial]], [[glNormal]], [[glTexCoord]], [[glVertex]]

[[Kategorie:GL|Begin]]
[[Kategorie:GL1.0]]

Konkav

2008-03-10T14:31:56Z

Wilson: Weiterleitung nach Konvex erstellt

#REDIRECT [[Konvex]]

Triangulation

2008-03-10T14:29:13Z

Wilson:

= Triangulation =
== Was ist das? ==
Triangulation steht für "Aufteilen der Polygone innerhalb der Szene in Dreiecke".<br>
Die Triangulation ist damit eine Spezialisierung der [[Tesselierung]].

== Wozu braucht man das? ==
Dazu muss man auf die Besonderheiten der Grafikhardware eingehen.
Heutzutage (und nicht erst seit gestern) werden Grafikkarten auf die Darstellung von (texturierten) Dreiecken optimiert (Linien und Punkte lasse ich mal außen vor). Das hat einen ganz einfachen Grund: <br>
Jedes Polygon kann als Zusammenstellung von Dreicken dargestellt werden.
<br>
Ihr könntet jetzt anbringen, dass ihr aber doch auch "Vierecke und Polygone mittels OpenGL zeichnen" könnt. (siehe Beitrag [[Primitive]])<br>
Das stimmt. Nur sind die Grafikkarten nunmal auf Dreiecke optimiert. Und wenn man was anderes als Dreiecke zeichnet, müssen diese Flächen erst für die Hardware in Dreiecke zerlegt werden. Und das kostet Zeit. Und Zeit ist etwas, was in der Programmierung (vorallem im Grafikbereich) so wertvoll ist wie der Kaffee in der Nacht. (Also quasi unersetzbar) <br>

===Fazit===
Wenn ihr die Möglichkeit habt, dann baut eure Szene von Anfang an aus Dreiecken auf. Die müssen nicht mehr nachbearbeitet werden, und das bringt euch vorallem bei großen Szenen noch einen spürbaren Geschwindigkeitszuwachs.

== Wie mach ich es? ==
Es wäre sicherlich mühselig nun anzufangen die komplette Szene aus einzelnen Dreiecken zusammenzusetzen. Glücklicherweise hat OpenGL dafür eine Lösung.<br>
Anstatt im glBegin-glEnd Block mit '''GL_TRIANGLES''' zu arbeiten könnt ihr zusammenhängende ('''GL_TRIANGLE_STRIP''') Dreiecke (für rechteckige Flächen oder Flächen die aus Rechtecken zusammengesetzt wurden) oder konzentrische ('''GL_TRIANGLE_FAN''') Dreiecke (für [[Konvex | konvexe]] Polygone) verwenden. Was diese Konstanten konkret verändern ist im Artikel [[glBegin]] beschrieben.

== Siehe auch ==
[[glBegin]], [[Primitive]]

Framecounter

2008-03-10T14:26:40Z

Wilson:

Wenn man in seinem Programm die [[Frame]]s pro Sekunde (FPS) anzeigen lassen möchte, so gibt es verschiedene Lösungswege.

== Methode 1 ==

Am Anfang der Renderschleife "misst" man die Zeit und speichert sie in einer Variable.
Dafür kann man die von Windows bereitgestellten Methoden [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp "Gettickcount"] (gibt in Millisekunden an, wie lange Windows läuft) oder [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Windowing/Timers/TimerReference/TimerFunctions/QueryPerformanceCounter.asp "QueryPerformanceCounter"] verwenden.
Für unsere Zwecke reichen diese beiden Funktionen vollkommen aus.

Als zweiten Schritt rendert man seine Szene, verarbeitet Tastatureingaben usw.
Also alles, was in der Renderschleife passiert.

Am Ende der Renderschleife stoppt man dann ein zweites Mal die Zeit und erhält nun eine Zeitdifferenz.

Die FPS erhält man nun durch folgende Berechnung:

FPS = 1000 / Zeitdifferenz;

Wobei Zeitdifferenz bei dieser Formel auch in Millisekunden angegeben sein muss.

== Methode 2 ==

Diese Methode unterscheidet sich kaum von Methode 1.
Wieder wird:
#Startzeit bestimmt
#gerendert
#Endzeitbestimmt
#Zeitdifferenz berechnet

Anschließend wird die Zeitdifferenz auf eine Variable TimeCount addiert. Außerdem wird eine Zählvariable für die Frames erhöht.

Wenn die Variable Timecount größer-gleich 1000 wird (es ist mindestens 1 sec vergangen) wird die Frameanzahl berechnet und ausgegeben.

Die Methode 2 hat gegenüber Methode 1 den Vorteil, dass die Frameanzahl nicht nach jedem Frame sondern maximal nur einmal pro Sekunde berechnet wird.

== Beispielcodes ==

Methode 2:
Der folgende Code wird im OnIdle-Event des OpenGL Formulars ausgeführt. Die Anzahl der Frames wird in der Beschriftung (Caption) des Fensters ausgegeben.

<pascal> procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
//
StartTime:= GetTickCount;

Render;

DrawTime:= GetTickCount - StartTime;

inc(TimeCount, DrawTime);
inc(FrameCount);

if TimeCount >= 1000 then begin
Frames:= FrameCount;
Dec(TimeCount, 1000);
FrameCount:= 0;

Caption:= InttoStr(Frames) + 'FPS';
end;

Done:= false;
end;</pascal>
[[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]]

Primitive

2008-03-10T14:25:03Z

Wilson:

= Primitive (Plural: Primitiven) =

== Einleitung ==

In OpenGL werden alle 3D- oder 2D-Objekte aus den von der API angebotenen Primitiven zusammengesetzt. Die GL stellt dazu insgesamt 10 verschiedene Primitiventypen zur Verfügung (darunter Punkt, Linie, Dreieck, Rechteck und [[Polygon]]e), von denen Dreiecke (oft auch als Abwandlung über Triangle-Strips oder -Fans) am häufigsten Verwendung finden. Dies ist u.a. damit zu erklären das sich fast alle Oberflächen recht genau mit Dreiecken beschreiben lassen (mit Vierecken wäre dies schon schwerer) und das moderne 3D-Beschleuniger (im Gegensatz zu den ersten Lösung, z.B. dem NV1 von NVidia, der Vierecke nutze) intern mit Dreiecken arbeiten. Dies hat auch zur Folge, das der Primitiventyp "Polygon" von der Grafikkarte erst in Dreiecke [[Tesselierung|tesseliert]] werden muss, weshalb dieser Primitiventyp recht selten genutzt wird.
Für den Programmierer bedeutet dies im Klartext, dass er beliebig komplexe Szenen mittels OpenGL visualisieren kann, mit der Einschränkung, dass er diese Szenen aus den vorhandenen Primitiven selbst erstellen muss.

Um das erstellen komplexer Szenen zu vereinfachen, kann man komplexere Grundkörper mit den gegeben Primitiven erstellen und in Bibliotheken zusammenfassen.
Eine solche Bibiothek wurde unter dem Namen [[OpenGL Programming Guide Auxiliary Library]] veröffentlich.

== Beispiele ==
{| width="100%"
|[[Bild:Primitive_geosphere.jpg|framed|Geosphäre, Zusammengesetzt aus Dreiecken (GL_TRIANGLES)]]
|[[Bild:Primitive_torus.jpg|framed|Torus, Zusammengesetzt aus Vierecken (GL_QUADS).]]
|[[Bild:Primitive_complexscene.jpg|framed|Eine komplexe Szene, wie man sie im Normalfall in Spielen oder anderen 3D-Anwendungen findet. Zusammengesetzt aus Dreiecken (Aufbauten), Vierecken (Seitenteile) und Dreiecks-Streifen (GL_TRIANGLESTRIP, Dach).]]
|-
|}

== Siehe auch ==

[[glBegin]]

Tiefentest

2008-03-10T14:20:28Z

Wilson:

Bei der Berechnung eines [[Fragment]]es, muss OpenGL feststellen können, welche Teile der Grafik im Vordergrund stehen und welche Objekte ganz oder teilweise durch andere Objekte verdeckt werden.

== Funktionsweise ==
Für den Tiefentest existiert der [[Tiefenpuffer]]. Dieser ist genauso gross wie der Framebuffer. Für jeden Pixel auf dem Bildschirm gibt es dann also einen weiteren Wert - den Eintrag im Tiefenpuffer.

Im ersten Schritt wird der gesamte Tiefenpuffer auf den größtmöglichen Wert initialisiert (also die maximale Distanz, siehe [[glClear]] und [[glClearDepth]]).
Sobald dann ein Objekt gerendert wird, wird für jeden Pixel überprüft, ob der Tiefenwert des Pixels dieses Objekts kleiner ist als der Wert im Tiefenpuffer. Ist dies der Fall, wird dieses Pixel in den Framebuffer gezeichnet und der Tiefenpuffer aktualisiert, ansonsten wird es verworfen. Der Test kann mittels [[glDepthFunc]] auch abgeändert werden. Zum Beispiel kann man dafür sorgen, dass auch gleich große Tiefenwerte akzeptiert werden.

Der Tiefentest findet verhältnismäßig früh in der [[Feste_Funktionspipeline#Fragment_Pipeline|Fragment-Pipeline]] statt, wodurch er sehr effizient nicht benötigte Fragmente ausschließen kann. Wenn Objekte tiefensortiert (in diesem Fall von vorne nach hinten) gezeichnet werden, ist der Tiefentest sehr gut geeignet um sehr früh nicht benötigte Fragmente zu verwerfen um so die [[Füllrate]] zu schonen.

Den Tiefentest aktiviert man mit [[glEnable#GL_DEPTH_TEST|glEnable(GL_DEPTH_TEST)]] und deaktiviert ihn entsprechend mit glDisable.

=== Beispiel ===

[[Bild:Depthtest_nt_enabled.jpg|thumb|200px|Aktivierter Tiefentest]]
[[Bild:Depthtest_nt_disabled.jpg|thumb|200px|Deaktivierter Tiefentest]]
Dieser Rendercode wird einmal mit und einmal ohne Tiefentest verwendet.
glBegin(GL_QUADS);
glColor4f(1.0, 0.5, 0.5, 1.0);
glVertex3f(-1.0, 0.0, -1.0);
glVertex3f(-1.0, 0.0, 1.0);
glVertex3f(1.0, 0.0, 1.0);
glVertex3f(1.0, 0.0, -1.0);

glColor4f(0.5, 1.0, 0.5, 1.0);
glVertex3f(-1.0, 0.5, -1.0);
glVertex3f(-1.0, 0.5, 1.0);
glVertex3f(1.0, 0.5, 1.0);
glVertex3f(1.0, 0.5, -1.0);
glEnd;

Man kann deutlich erkennen, dass bei deaktiviertem Tiefentest das eigentlich vorne liegende rote Quad vom weiter hinten liegenden, allerdings später gerenderten, grünen Quad überdeckt wird.

== Transparenz und Tiefentest ==
Sobald Transparenz verwendet wird, kann der Tiefentest zumindest für diese Teile nicht mehr benutzt werden. Dies würde zu Fehlern führen, da das transparente Fragment ggfs. das durchscheinende, jedoch erst später an die Grafik-Pipeline gesendete und somit vom Tiefentest verworfene Fragment dahinter völlig verbirgt. Wenn man Transparente Fragmente nicht in den Tiefenbuffer schreibt, so können diese Fragmente von anderen, eigentlich weiter hinten liegenden, Fragmenten komplett überschrieben werden.<br>
Aus diesem Grund sollten Transparente Objekte nach allen anderen Objekten an OpenGL geschickt werden und diese möglichst von hinten nach vorne sortiert sein. Das Sortieren kann durch einen Alpha Wert im [[Framebuffer]] umgangen werden, jedoch ist dieser nur selten in Hardware vorhanden, wodurch in den weit langsameren Softwaremodus gewechselt wird.

Tutorial Objekt gedreht und dennoch nach vorne bewegt

2007-10-13T12:19:57Z

Wilson: /* Und wie geht's jetzt weiter? */

==Vorwort==

Beim Erstellen eines 3D-Games steht man irgendwann vor einem gewaltigen Problem: Ich kann zwar mein Objekt drehen und Transformieren, aber was mache ich, wenn sich das Objekt an der aktuellen Position um z.B. 15 Grad drehen und trotzdem in seine Blick-Richtung bewegen soll?!?

Die Lösung des Problems heißt: Look-Vektor!!! Look was?!? Keine Panik, ich wird's euch erklären.

==Der Richtungs-Vektor==

Um ein Objekt immer nach vorne bewegen zu können, muss ich wissen, wo momentan für das Objekt vorne ist. Dazu benötige ich den Richtungs-Vektor (ich nenne ihn mal Look-Vektor) Bei einer Drehung des Objektes, wird der Vektor mitgedreht und zeigt somit immer nach vorn. Klingt komisch, ist aber so :o) Nein, im ernst: Es ist eigentlich kein Problem wie ihr sehen werdet.

==Bevor wir anfangen...==

...gibt es noch ein paar Kleinigkeiten zu regeln.
*um ein Objekt wie z.B. einen Raumgleiter in einer entsprechenden Simulation zu bewegen, müssen 3 Lokale Vektoren mitverwendet werden, welche ein lokales Koordinatensystem darstellen. Mit diesem Lokalen Koordinatensystem muss dann bei Drehungen gearbeitet werden. Das kommt aber in ein anderes Tutorial. Hier wird das ganze nur mit einem Vektor gemacht, was für den Anfang das Prinzip hinter der ganzen Geschichte verdeutlichen soll.
*Um die Vektor-Rotation durchführen zu können, verwende ich die Geometry.pas von GLScene. Bei dieser Datei handelt es sich um eine Ansammlung ziemlich nützlicher mathematischer Prozeduren welche teilweise sogar für 3Dnow ™ optimiert sind. Ursprünglich (ohne Optimierung für 3Dnow ™) kommt diese Unit von Mike Lischke.
*Ich gehe davon aus, dass ihr bereits wisst, wie ein Objekt mit Hilfe von glRotate gedreht, glTranslate positioniert und Objekte mit den entsprechenden Funktionen darstellt. Solltet ihr über dieses Wissen nicht verfügen, schaut euch die anderen Tutorials an. (z.B. [[Tutorial Matrix2]])
*Ihr wisst bescheid, was ein Vektor ist und was er macht. Wenn nicht: ein Vektor ist ein Zeiger von Punkt A auf Punkt B. A ist meistens der 0-Punkt des globalen Koordinatensystems und B die Position eures Objektes im 3D-Raum. Ok, das war der Vektor in Grob-Form.
*Das Ganze baut auf das API-Tutorial 2 auf. Es wurden eigentlich nur die Funktionen glDraw und ProcessKeys geändert.

==Und los gehts==

Da wir unser Objekt Rotieren, benötigen wir erst einmal die Variablen um die Rotation der entsprechenden Achse zu merken, sowie den Vektor welcher die Position unseres Objektes beinhaltet. Dieser ist in der Geometry.pas deklariert:
<pascal>
var
RotateX : single; // Rotation um die X-Achse
RotateY : single; // Rotation um die Y-Achse
RotateZ : single; // Rotation um die Z-Achse
PosVect : TVector3f; // Vector mit der Position des Objektes.
</pascal>
Diese Variablen werden in der WndProc mit den Standard-Werten initialisiert. Dabei wird für den Positions-Vektor der Z Wert auf -5 gesetzt, damit das Objekt überhaupt mal sichtbar ist.
<pascal>
RotateX := 0;
RotateY := 0;
RotateZ := 0;
PosVect[0] := 0;
PosVect[1] := 0;
PosVect[2] := -5;
</pascal>
So, nun kommen wir zu glDraw. Auch hier läuft alles nach dem alt bekannten System ab. Bildschirm und Z-Buffer löschen, Objekt positionieren, rotieren und dann zeichnen. Letzteres wurde von mir in die Prozedur DrawTheObject ausgelagert, um die glDraw nicht ganz so unübersichtlich zu gestallten. Es gibt eigentlich nur zwei Erweiterungen zum Tutorial 2.

Die erste: Das Objekt wird um die X, Y und Z Achse gedreht wird, je nach Wert der Rotations-Variablen. Dabei ist die Reichenfolge von Zuerst X, Y, Z einzuhalten, da es sonst unerwünschten Resultaten kommt. (Echt witzig. Probiert's mal aus ;o) ). Die zweite: für Translate werden nun nicht mehr Fix-Werte verwendet, sondern die aktuellen Verte des Vektors welcher die aktuelle Position des Objektes beinhaltet.
<pascal>
glClearColor(0,0,0,0);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

glLoadIdentity;

// Das Objekt auf seine aktuelle Position setzen.
glTranslate( PosVect[0], PosVect[1], PosVect[2]);

{ Das Objekt noch drehen, damit denn wir haben bis jetzt ja nur den }
{ Vector gedreht. }
glRotate(RotateX, 1, 0, 0);
glRotate(RotateY, 0, 1, 0);
glRotate(RotateZ, 0, 0, 1);

DrawTheObject;
</pascal>
Die Prozedur DrawTheObject muss hier nicht weiter aufgelistet werden, da dort nur die (ständig unveränderten) Objekt-Daten an OpenGL weitergeleitet werden. Bis jetzt nichts außergewöhnliches, oder ?!?

==Die Tasten-Verarbeitung==

ProcessKey wurde ebenfalls ein kleinwenig angepasst. Hier werden die Tasten R (für Reset), W, S, A, D, Links, Rechts, Oben und Unten abgefragt und entsprechend reagiert. Dabei wird mit W und S das Objekt in der X-Achse gedreht, mit A und D in der Y Achse und mit Rechts und Links in der Z Achse. R setzt alles Werte wieder auf den Standard zurück. Ich führe hier nur als Beispiel die Abfrage für die X Achse an. R ist selbsterklärend und auf Oben und Unten gehe ich später noch genauer ein.

Eigentlich wird hier nichts besonderes gemacht: Die Variable mit den Rotations-Daten werden entsprechend der gedrückten Taste angepasst. Sollte der Winkel 360 Grad über- oder 0 Grad unterschreiten, wird entsprechend zurückgesetzt, damit ein Drehwinkel von 0 - 360 Grad eingehalten wird. Ich habe übrigens für jede Rotation eine eigene Prozedur geschrieben um das ganze etwas übersichtlicher zu halten:
<pascal>
// Überprüfen, ob W gedrückt wurde (Drehung um X-Achse)
if Keys[ord('W')] then
begin
//--- Die Rotation um die X-Achse erhöhen. ---------------------------------
RotateX := RotateX + 0.8;
//--- Sollte RotateX größer als 360 Grad sein, den Wert umrechnen. Dadurch
// wird der Drehungs-Bereich auf 0 - 360 Grad begrenzt.
if RotateX > 360 then RotateX := RotateX - 360;
end;

// Überprüfen, ob W gedrückt wurde (Drehung um X-Achse)
if Keys[ord('S')] then
begin
//--- Die Rotation um die X-Achse erniedrigen. -----------------------------
RotateX := RotateX - 0.8;
//--- Sollte RotateX kleiner als 0 Grad sein, den Wert umrechnen. Dadurch
// wird der Drehungs-Bereich auf 0 - 360 Grad begrenzt.
if RotateX <= 0 then RotateX := RotateX + 360;
end;
</pascal>
Ich denke, mit Hilfe der Kommentare dürften alle übriggebliebenen Fragen geklärt sein (scheint so, als wäre ich Optimist *grins*). Wenn euch die Rotation zu langsam ist, verwendet einfach an Stelle von 0.8 einen anderen Wert. Je größer, um so schneller ist die Rotation.

==Das ganze ist ein auf und ab...==

Ich hab's euch versprochen: auf die Oben und Unten-Taste gehe ich genauer ein. Der Grund ist ganz einfach: hier spielt sich der eigentliche Vektor-Rotations-Vorgang ab. Hier liegt das Geheimnis. Aber keine Angst, ich gehe, wie versprochen, genauer darauf ein. Hier ist nur mal die Vollständige Prozedur:
<pascal>
procedure UpdateMovement;
const
RotXAxis : TVector3f = (1, 0, 0);
RotYAxis : TVector3f = (0, 1, 0);
RotZAxis : TVector3f = (0, 0, 1);
var
Direction : single;
LookVec : TVector4f;
begin
// Ist die Vorwärts-Taste gedrückt? Wenn ja, nach vorne gehen.
if Keys[VK_UP] then Direction := 1 else
// Ist die Rückwärtstaste gedrückt? Wenn ja, nach hinten gehen.
if Keys[VK_DOWN] then Direction := -1 else
// Wenn keine der beiden Tasten gedrückt wurde, kann die Prozedur
// verlassen werden, da dann keine Positions-Anpassung notwendig
// ist
Exit;

// Den Blickrichtungs-Vektor initialisieren. Hier soll nur nach vorne,
// also in die Y-Richtung geschaut werden.
LookVec[0] := 0;
LookVec[1] := 1;
LookVec[2] := 0;
// Den W-Wert auf 0 setzen. Wir benötigen ihn nicht.
LookVec[3] := 0;

// Den Look-Vektor zuerst um die Z-Achse...
RotateVector(LookVec, RotZAxis, -DegToRad(RotateZ));
// ...um die Y-Achse...
RotateVector(LookVec, RotYAxis, -DegToRad(RotateY));
// ... und um die X-Achse drehen.
RotateVector(LookVec, RotXAxis, -DegToRad(RotateX));

// Nun den gedrehten Vector zum Aktuellen Positions-Vektor
// hinzuzählen. Damit die Bewegung beachtet wird, das ganze
// um den Speed-Faktor 0.01 mal Direction multiplizieren.
PosVect[0] := PosVect[0] + (LookVec[0] * (Direction * 0.01));
PosVect[1] := PosVect[1] + (LookVec[1] * (Direction * 0.01));
PosVect[2] := PosVect[2] + (LookVec[2] * (Direction * 0.01));
end;
</pascal>
Eigentlich gar nicht viel, oder?!? Fangen wird am Anfang an. Wenn ich das Objekt in seiner Position verändern will (durch betätigen der Oben bzw. Unten Tasten), so muss ich zuerst einmal feststellen, in welche Richtung das Objekt verschoben werden soll:
<pascal>
// Ist die Vorwärts-Taste gedrückt? Wenn ja, nach vorne gehen.
if Keys[VK_UP] then Direction := 1 else
// Ist die Rückwärtstaste gedrückt? Wenn ja, nach hinten gehen.
if Keys[VK_DOWN] then Direction := -1 else
// Wenn keine der beiden Tasten gedrückt wurde, kann die Prozedur
// verlassen werden, da dann keine Positions-Anpassung notwendig
// ist
Exit;
</pascal>
Sollte keine der beiden Tasten betätigt worden sein, dann MUSS die Funktion verlassen werden, um keine falschen Rechnungen durchzuführen. Sonst kann es sein, dass sich das Objekt ohne eure Kontrolle dauernd verschiebt. Ok, wenn ich also nach oben gehen will, wird Direction auf 1 und anderen Falls auf -1 gesetzt. Ich Denke, der Grund dürfte Klar sein: 1 -> vorwärts und -1 -> Rückwärts. Das ganze basiert auf einfachste Mathematik ;o) (Ja, wirklich, man benötigt kein ABI, um 3D-Progger zu sein!!!)

Als nächstes wird mein Richtungs-Vektor initialisiert. Der 2 Eintrag (Y Achse) wird auf 1 gesetzt, da der Richtungs-Vektor in der Null-Stellung des Objektes parallel zur Y Achse steht. Der Grund: das Objekt "blickt" am Anfang oder nach einem Reset auf die Caption des Fensters.
<pascal>
// Den Blickrichtungs-Vektor initialisieren. Hier soll nur nach vorne,
// also in die Y-Richtung geschaut werden.
LookVec[0] := 0;
LookVec[1] := 1;
LookVec[2] := 0;
// Den W-Wert auf 0 setzen. Wir benötigen ihn nicht.
LookVec[3] := 0;
</pascal>
Lasst euch von der letzten Zeile nicht irritieren. Es gibt auch noch Vektoren welche einen W-Wert haben. Die RotateVector Funktion arbeitet mit einem solchen Vektor, da bei der Rotation ein Vektor mit einer Rotations-Matrix verrechnet wird, und diese eben ein 4x4 Feld hat. Aus diesem Grund wurde auch der TVector4f Typ verwendet. -> Ignoriert es einfach, der Wert wird sowieso nicht benötigt und sollte deswegen auf 0 stehen.

Nun wird der Vektor um die 3 Achsen gedreht. Da die RotateVector-Funktion einen "Standard-Vektor" (also mit X, Y und Z Wert) benötigt um zu wissen, um welche Achse gedreht werden soll, sind diese am Anfang der Prozedur im const-Bereich als Rot[Achse]Axis definiert. Das ist übrigens das gleiche wie bei glRotate, nur das dort die X, Y und Z Werte getrennt und in einem Vektor zusammengefasst übergeben werden. Hier ist es übrigens auch sehr wichtig, die umgekehrte Reihenfolge zu verwenden. Also zuerst Drehung um die Z, dann um die Y und zum Schluss um die X Achse. Warum weis ich leider auch nicht. Der Winkel muss hier in einen RAD konvertiert werden, da die Funktion nicht mit GRAD angaben arbeitet. Außerdem muss der Winkel noch Invertiert, also mit einem - versehen werden, da sonst der Vektor in die entgegengesetzte Richtung zum Objekt gedreht wird. Ist nicht das was wir wollen. Warum genau, kann ich nicht so direkt erklären. Aber man muss auch nicht alles wissen ;o) Wenn es aber doch jemand weis warum, darf er mir das durchaus mitteilen. Ich lerne gerne dazu!
<pascal>
// Den Look-Vektor zuerst um die Z-Achse...
RotateVector(LookVec, RotZAxis, -DegToRad(RotateZ));
// ...um die Y-Achse...
RotateVector(LookVec, RotYAxis, -DegToRad(RotateY));
// ... und um die X-Achse drehen.
RotateVector(LookVec, RotXAxis, -DegToRad(RotateX));
</pascal>
Eigentlich gar nicht schwer, oder?!?

==Ein kleiner Ausflug==

Ok, ganz ohne Mathematik geht es leider doch nicht. Jetzt haben wird den gedrehten Vektor und wissen, in welcher Richtung vorne liegt. Aber wie bekomme ich aus dieser Information meine neue Objekt-Position?!? Das Stichwort heißt: Vektor-Arithmetik. Keine Angst, ist nicht schlimm. Folgende "Skizze" soll helfen, sich das Ganze vorzustellen:

[[Bild:Tutorial_Objekt_gedreht_und_dennoch_nach_vorne_bewegt_Skizze.gif]]

Wir haben einen Vektor, welcher von A nach B zeigt (ich nenne ich AB). Und wird haben einen, welcher von B nach C Zeigt (BC). Letzterer ist unser Richtungs-Vektor. Ok, so weit so gut, aber wir benötigen einen neuen Positions-Vektor : AC. Denn die neue Position ist C also muss ein Vektor von A (Ursprung) nach C (neue Position) zeigen. Den erhalten wir ganz einfach. Wirklich kein Problem. Einfachste Mathematik:

:AC = AB + BC

Boah ey... cool, oder? So einfach und schon haben wir die neue Position. DAS war Vektor-Arithmetik. Ein Kumpel sagte mal, das Matrizen und Vektoren Rechnung eigentlich wirklich nicht kompliziert ist. Und er hatte recht. +, - ,* und / ist doch wirklich kein Problem, oder?!?

==Das neue Ziel==

Ok, nun addieren wir einfach die beiden Vektoren miteinander. Der Richtungs-Vektor muss nur noch etwas "verlängert" werden. Denn bisher haben wir nur die Richtung. Das ganze mit einer Zahl (z.B. 5) multiplizieren, und wir haben unser Objekt 5 Schritte in Blickrichtung bewegt. Hä?!? Warum soll bitte Mathe für 3D-Progger schwer sein?!?

Ich habe das ganze hier so gelöst: Ich multipliziere den Vektor mit der Geschwindigkeit, mit welcher er sich bewegen soll. Erinnert ihr euch noch an Direction? Ja? Gut. Denn somit haben wir die Schritt-Weite. Entweder ein Schritt nach vorne, oder -1 Schritt nach vorne was einem Schritt nach hinten entspricht! Das ganze sieht dann so aus:
<pascal>
// Nun den gedrehten Vektor zum Aktuellen Positions-Vektor
// hinzuzählen. Damit die Bewegung beachtet wird, das ganze
// um den Speed-Faktor 0.01 mal Direction multiplizieren.
PosVect[0] := PosVect[0] + (LookVec[0] * (Direction * 0.01));
PosVect[1] := PosVect[1] + (LookVec[1] * (Direction * 0.01));
PosVect[2] := PosVect[2] + (LookVec[2] * (Direction * 0.01));
</pascal>
0.01 ist hier dann die Geschwindigkeit und kann nach Lust und Laune von Euch verändert werden.

==Happy End?!?==

Wie, DAS war alles? Ja. Es ist gar nicht so schwer wenn man weis, wie es geht. Und dank der Funktionen der Geometry.pas wird einem einiges abgenommen. Die Rotation eines Vektors selber ist eigentlich auch nicht sooo kompliziert, nur IMO etwas schwer zu erklären.

==Und wie geht's jetzt weiter?==

Das liegt an Euch. Wie gesagt: in unserem Beispiel bewegt sich das Objekt nicht ganz so, wie man es von einem Raumgleiter gewöhnt ist. Das Problem ist ganz einfach erklärt: Das Objekt dreht sich immer um das globale Koordinatensystem. Um also die richtige Drehung durch zu führen, muss ein lokales Koordinatensystem mitgeführt werden. Also 3 Vektoren anstelle von einem. Aber dafür gibt's später mal ein anderes Tutorial. Jetzt geht's erst mal in Urlaub ;o)

Außerdem ist hier überhaupt kein Wert auf Optimierung gelegt worden, sondern es ging nur um das Verständnis der Materie selber.

Viel Spaß beim Proggen und liefert DGL ne menge Feedback!!!

Euer

SchodMC

{{TUTORIAL_NAVIGATION| [[Tutorial Nachsitzen]] | [[Tutorial Objekt immer um eigene Achse drehen]]}}

[[Kategorie:Tutorial|Objekt gedreht]]

Timebased Movement

2007-07-29T10:04:14Z

Wilson: /* Prinzip */

== Kurz-Beschreibung ==
'''Timebased Movement''' sorgt dafür, dass die Bewegungsgeschwindigkeiten nicht vom CPU-/Renderspeed abhängen.

== Prinzip ==
Nehmen wir an wir möchten einen Ball darstellen der sich mit konstanter Geschwindigkeit vom linken Bildschirmrand zum rechten Bildschirmrand bewegt.

Das erste Bild wird den Ball ganz links zeigen. Auf dem nächsten Bild wird der Ball ein Stück weiter sein, die Frage ist nur wie weit? Die Länge der Strecke die der Ball zurücklegen muss legen wir nun mal willkürlich auf 1 Längeneinheit (kurz: LE) fest. Die Strecke soll er in 5 Sekunden zurück legen.

Ein Rechner A braucht 1 Sekunde um 1 Bild zu Berechnen. Um das gewünschte Ergebnis zu erreichen müssten wir den Ball nach jedem Bild 0.2 Felder weiterbewegen.

In einer Sekunde hätten wir also folgende Bilder:
* Bild 0: Ball Position: 0.0
* Bild 1: Ball Position: 0.2 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 2: Ball Position: 0.4 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 3: Ball Position: 0.6 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 4: Ball Position: 0.8 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 5: Ball Position: 1.0 (weiterbewegt um 0.2 LE in 1.0 Sekunden)

Ein Rechner B braucht nur 0.5 Sekunden um ein Bild zu berechnen.

Ebenfalls in nur einer Sekunde hätten wir folgende Bilder:
* Bild 0: Ball Position: 0.0
* Bild 1: Ball Position: 0.1 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 2: Ball Position: 0.2 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 3: Ball Position: 0.3 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 4: Ball Position: 0.4 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 5: Ball Position: 0.5 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 6: Ball Position: 0.6 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 7: Ball Position: 0.7 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 8: Ball Position: 0.8 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 9: Ball Position: 0.9 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 10: Ball Position: 1.0 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)

Bei dem einen Rechner muss der Ball bei jedem Bild um 0.2 LE bewegt werden, beim andern Rechner nur 0.1 LE pro Bild. Tut man dies nicht, bewegt sich der Ball zu schnell oder zu langsam.

Doch woher weiß man nun wie weit man seinen Ball auf den jeweiligen Rechner pro Bild bewegen muss?

In unserem Beispiel bewegt sich der Ball mit der konstanten Geschwindigkeit von 0.2 LE pro Sekunde. Mit folgender Formel können wir bei konstanter Geschwindigkeit die neue Position berechnen:

neue_Position = Geschwindigkeit * vergangene_Zeit + alte_Position

Wir brauchen also nur eine Geschwindigkeit festlegen und messen, wie viel Zeit vergangen ist, um die neue Position zu berechnen zu können.

Wohlgemerkt gilt diese Formel nur wenn sich das Objekt mit konstanter Geschwindigkeit fortbewegt.

== Berechnung der vergangen Zeit ==

Allgemein:
VergangeneZeit := ( Zeit1 - Zeit0 ) / Frequenz;

=== Millisekunden genau unter Windows===
Die wohl einfachste aber auch ungenaueste Möglichkeit unter Windows so etwas zu realisieren besteht darin mit Hilfe von GetTickCount die Zeit (in Millisekunden) seit dem letzen Windows-Start zu ermitteln.

<pascal>
//Benötigte Variablen
var
BerechnungsZeit : LongWord;
Position : Double;

procedure BeimStart; // Was hier drinnen steht sollte zum Start ausgeführt werden
begin
BerechnungsZeit := GetTickCount();
end;

procedure BerechnungsCheck; // Alle nötigen Berechnungen durchführen
const
Frequenz = 1000; // Durch Windows festgelegt
var
AktuelleZeit : LongWord;
begin
AktuelleZeit := GetTickCount();
Berechne((AktuelleZeit - BerechnungsZeit) / Frequenz);
BerechnungsZeit := AktuelleZeit;
end;

procedure Berechne(vergangene_Zeit : Double);
const
Geschwindigkeit = 0.5;
begin
{Alle Berechnungen stehen hier }
// z.B.
Position := Geschwindigkeit * vergangene_Zeit + Position;
end;
</pascal>

=== Absolute Genauigkeit per Hardware ===
Man kann auch die Hardware zur Zeitmessung nutzen um so noch genauere Ergebnisse zu erziehlen. Es kann jedoch theoretisch sein, dass diese nicht zur Verfügung steht.
<pascal>
//Benötigte Variablen
var
BerechnungsZeit : Int64;
Frequenz : Int64;
Position : Double;

procedure BeimStart; // Was hier drinnen steht sollte zum Start ausgeführt werden
begin
if not QueryPerformanceFrequency(Frequenz) then // Frequenz ermitteln
raise Exception.create('Kein Hardware Timer vorhanden');
QueryPerformanceCounter(BerechnungsZeit); // Aktuelle Zeit ermitteln
end;
procedure BerechnungsCheck; // Alle nötigen Berechnungen durchführen
var
AktuelleZeit : Int64;
begin
QueryPerformanceCounter(AktuelleZeit);
Berechne((AktuelleZeit - BerechnungsZeit) / Frequenz);
BerechnungsZeit := AktuelleZeit;
end;
procedure Berechne(vergangene_Zeit : Double);
const
Geschwindigkeit = 0.5;
begin
{Alle Berechnungen stehen hier }
// z.B.
Position := Geschwindigkeit * vergangene_Zeit + Position;
end;
</pascal>

Man hat nun den Speedfactor, den man mit sämtlichen Bewegungen multipliziert. Wenn der PC viele Frames per Second rendert wird der Speedfactor klein. Die Bewegungen werden dadurch naturlich auch kleiner. Wenn der PC wenige Frames per Second rendert wird der Speedfactor groß, die Bewegungen also auch größer.

== Konstant Beschleunigte Bewegung ==

Nehmen wir an wir möchten darstellen wie ein Ball zu Boden fällt. Der Ball sei 1 LE über dem Boden und wird dort zum Zeitpunkt 0s losgelassen. Die Kraft welche die Erdanziehung simuliert soll pro Sekunde die Geschwindigkeit des Balles um 1 LE/s erhöhen.

Die neue Geschwindigkeit die sich durch die Beschleunigung ergeben hat, läßt sich noch sehr einfach Berechnen:
neue_Geschwindigkeit := Beschleunigung * vergangene_Zeit + alte_Geschwindigkeit;

Wie sieht es aber mit der Position aus?

Falsch wäre diese Berechnung:
neue_Position := alte_Geschwindigkeit * vergangene_Zeit + alte_Position
Denn so würde sich der Ball von Bild 0 nach Bild 1 gar nicht bewegen.

Genauso falsch wäre diese Berechnung:
neue_Position := neue_Geschwindigkeit * vergangene_Zeit + alte_Position

Denn dann würde sich der Ball sofort mit der vollen Geschwindigkeit bewegen und wäre viel zu schnell ab Boden.

Wer sich ein wenig mit Physik auskennt weiß das man bei konstant Beschleunigter Bewegung so die neue Position ausrechnet:
neue_Position := 0.5 * Beschleunigung * vergangene_Zeit * vergangene_Zeit + Geschwindigkeit * vergangene_Zeit + alte_Position

Beispielcode:
<pascal>
var
Position : Double;
Geschwindigkeit : Double;
procedure Berechne(vergangene_Zeit : Double);
const
Beschleunigung = 1;
begin
Position := 0.5*Beschleunigung * vergangene_Zeit * vergangene_Zeit + Geschwindigkeit * vergangene_Zeit + Position
// Wichtig: alte Geschwindigkeit erst ändern wenn sie nicht mehr gebraucht wird.
Geschwindigkeit := Beschleunigung * vergangene_Zeit + Geschwindigkeit
end;
</pascal>

== Umsetzung mit einer Delphi Form ==
<pascal>
var
[...]
Frequency, StartCount, EndCount: Int64;
Speedfactor: Extended;

const
Scalefactor = 100; //Der Scalefactor ist ein beliebiger Wert um den Speedfactor
//zu beeinflussen
[...]
procedure TForm1.FormCreate(Sender: TObject);
begin
if not QueryPerformanceFrequency(Frequency) then
raise Exception.create('Kein Hardware Timer vorhanden');
QueryPerformanceFrequency(Frequency); //Frequenz des Rechners ermitteln
[...]
end;

procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
QueryPerformanceCounter(StartCount); //Zeit0
Form1.Render;
QueryPerformanceCounter(EndCount); //Zeit1
Speedfactor := ((EndCount - StartCount) /Frequency) * Scalefactor //(Zeit1 - Zeit0) / Frequenz
[...]
end;
</pascal>

Man hat nun den Speedfactor, den man mit sämtlichen Bewegungen multipliziert. Und schon hat man eine einfache Umsetzung von Timebased movement, ohne sich über Physik Gedanken machen zu müssen.

== Links ==
*[http://www.delphigl.com/script/do_show.php?name=bombman2&action=2 Bomberman DGL-Tutorial]

Timebased Movement

2007-07-29T10:03:41Z

Wilson: /* Prinzip */

== Kurz-Beschreibung ==
'''Timebased Movement''' sorgt dafür, dass die Bewegungsgeschwindigkeiten nicht vom CPU-/Renderspeed abhängen.

== Prinzip ==
Nehmen wir an wir möchten einen Ball darstellen der sich mit konstanter Geschwindigkeit vom linken Bildschirmrand zum rechten Bildschirmrand bewegt.

Das erste Bild wird den Ball ganz links zeigen. Auf dem nächsten Bild wird der Ball ein Stück weiter sein, die Frage ist nur wie weit? Die Länge der Strecke die der Ball zurücklegen muss legen wir nun mal willkürlich auf 1 Längeneinheit (kurz: LE) fest. Die Strecke soll er in 5 Sekunden zurück legen.

Ein Rechner A braucht 1 Sekunde um 1 Bild zu Berechnen. Um das gewünschte Ergebnis zu erreichen müssten wir den Ball nach jedem Bild 0.2 Felder weiterbewegen.

In einer Sekunde hätten wir also folgende Bilder:
* Bild 0: Ball Position: 0.0
* Bild 1: Ball Position: 0.2 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 2: Ball Position: 0.4 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 3: Ball Position: 0.6 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 4: Ball Position: 0.8 (weiterbewegt um 0.2 LE in 1.0 Sekunden)
* Bild 5: Ball Position: 1.0 (weiterbewegt um 0.2 LE in 1.0 Sekunden)

Ein Rechner B braucht nur 0.5 Sekunden um ein Bild zu berechnen.

Ebenfalls in nur einer Sekunde hätten wir folgende Bilder:
* Bild 0: Ball Position: 0.0
* Bild 1: Ball Position: 0.1 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 2: Ball Position: 0.2 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 3: Ball Position: 0.3 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 4: Ball Position: 0.4 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 5: Ball Position: 0.5 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 6: Ball Position: 0.6 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 7: Ball Position: 0.7 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 8: Ball Position: 0.8 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 9: Ball Position: 0.9 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)
* Bild 10: Ball Position: 1.0 (weiterbewegt um: 0.1 LE in 0.5 Sekunden)

Bei dem einen Rechner muss der Ball bei jedem Bild um 0.2 LE bewegt werden, beim andern Rechner nur 0.1 LE pro Bild. Tut man dies nicht, bewegt sich der Ball zu schnell oder zu langsam.

Doch woher weiß man nun wie weit man seinen Ball auf den jeweiligen Rechner pro Bild bewegen muss?

In unserem Beispiel bewegt sich der Ball mit der konstanten Geschwindigkeit von 0.2 LE pro Sekunde. Mit folgender Formel können wir bei konstanter Geschwindigkeit die neue Position berechnen:

neue_Position = Geschwindigkeit * vergangene_Zeit + alte_Position

Wir brauchen also nur eine Geschwindigkeit festlegen und messen wie viel Zeit vergangen ist um die neue Position zu berechnen zu können.

Wohlgemerkt gilt diese Formel nur wenn sich das Objekt mit konstanter Geschwindigkeit fortbewegt.

== Berechnung der vergangen Zeit ==

Allgemein:
VergangeneZeit := ( Zeit1 - Zeit0 ) / Frequenz;

=== Millisekunden genau unter Windows===
Die wohl einfachste aber auch ungenaueste Möglichkeit unter Windows so etwas zu realisieren besteht darin mit Hilfe von GetTickCount die Zeit (in Millisekunden) seit dem letzen Windows-Start zu ermitteln.

<pascal>
//Benötigte Variablen
var
BerechnungsZeit : LongWord;
Position : Double;

procedure BeimStart; // Was hier drinnen steht sollte zum Start ausgeführt werden
begin
BerechnungsZeit := GetTickCount();
end;

procedure BerechnungsCheck; // Alle nötigen Berechnungen durchführen
const
Frequenz = 1000; // Durch Windows festgelegt
var
AktuelleZeit : LongWord;
begin
AktuelleZeit := GetTickCount();
Berechne((AktuelleZeit - BerechnungsZeit) / Frequenz);
BerechnungsZeit := AktuelleZeit;
end;

procedure Berechne(vergangene_Zeit : Double);
const
Geschwindigkeit = 0.5;
begin
{Alle Berechnungen stehen hier }
// z.B.
Position := Geschwindigkeit * vergangene_Zeit + Position;
end;
</pascal>

=== Absolute Genauigkeit per Hardware ===
Man kann auch die Hardware zur Zeitmessung nutzen um so noch genauere Ergebnisse zu erziehlen. Es kann jedoch theoretisch sein, dass diese nicht zur Verfügung steht.
<pascal>
//Benötigte Variablen
var
BerechnungsZeit : Int64;
Frequenz : Int64;
Position : Double;

procedure BeimStart; // Was hier drinnen steht sollte zum Start ausgeführt werden
begin
if not QueryPerformanceFrequency(Frequenz) then // Frequenz ermitteln
raise Exception.create('Kein Hardware Timer vorhanden');
QueryPerformanceCounter(BerechnungsZeit); // Aktuelle Zeit ermitteln
end;
procedure BerechnungsCheck; // Alle nötigen Berechnungen durchführen
var
AktuelleZeit : Int64;
begin
QueryPerformanceCounter(AktuelleZeit);
Berechne((AktuelleZeit - BerechnungsZeit) / Frequenz);
BerechnungsZeit := AktuelleZeit;
end;
procedure Berechne(vergangene_Zeit : Double);
const
Geschwindigkeit = 0.5;
begin
{Alle Berechnungen stehen hier }
// z.B.
Position := Geschwindigkeit * vergangene_Zeit + Position;
end;
</pascal>

Man hat nun den Speedfactor, den man mit sämtlichen Bewegungen multipliziert. Wenn der PC viele Frames per Second rendert wird der Speedfactor klein. Die Bewegungen werden dadurch naturlich auch kleiner. Wenn der PC wenige Frames per Second rendert wird der Speedfactor groß, die Bewegungen also auch größer.

== Konstant Beschleunigte Bewegung ==

Nehmen wir an wir möchten darstellen wie ein Ball zu Boden fällt. Der Ball sei 1 LE über dem Boden und wird dort zum Zeitpunkt 0s losgelassen. Die Kraft welche die Erdanziehung simuliert soll pro Sekunde die Geschwindigkeit des Balles um 1 LE/s erhöhen.

Die neue Geschwindigkeit die sich durch die Beschleunigung ergeben hat, läßt sich noch sehr einfach Berechnen:
neue_Geschwindigkeit := Beschleunigung * vergangene_Zeit + alte_Geschwindigkeit;

Wie sieht es aber mit der Position aus?

Falsch wäre diese Berechnung:
neue_Position := alte_Geschwindigkeit * vergangene_Zeit + alte_Position
Denn so würde sich der Ball von Bild 0 nach Bild 1 gar nicht bewegen.

Genauso falsch wäre diese Berechnung:
neue_Position := neue_Geschwindigkeit * vergangene_Zeit + alte_Position

Denn dann würde sich der Ball sofort mit der vollen Geschwindigkeit bewegen und wäre viel zu schnell ab Boden.

Wer sich ein wenig mit Physik auskennt weiß das man bei konstant Beschleunigter Bewegung so die neue Position ausrechnet:
neue_Position := 0.5 * Beschleunigung * vergangene_Zeit * vergangene_Zeit + Geschwindigkeit * vergangene_Zeit + alte_Position

Beispielcode:
<pascal>
var
Position : Double;
Geschwindigkeit : Double;
procedure Berechne(vergangene_Zeit : Double);
const
Beschleunigung = 1;
begin
Position := 0.5*Beschleunigung * vergangene_Zeit * vergangene_Zeit + Geschwindigkeit * vergangene_Zeit + Position
// Wichtig: alte Geschwindigkeit erst ändern wenn sie nicht mehr gebraucht wird.
Geschwindigkeit := Beschleunigung * vergangene_Zeit + Geschwindigkeit
end;
</pascal>

== Umsetzung mit einer Delphi Form ==
<pascal>
var
[...]
Frequency, StartCount, EndCount: Int64;
Speedfactor: Extended;

const
Scalefactor = 100; //Der Scalefactor ist ein beliebiger Wert um den Speedfactor
//zu beeinflussen
[...]
procedure TForm1.FormCreate(Sender: TObject);
begin
if not QueryPerformanceFrequency(Frequency) then
raise Exception.create('Kein Hardware Timer vorhanden');
QueryPerformanceFrequency(Frequency); //Frequenz des Rechners ermitteln
[...]
end;

procedure TForm1.IdleHandler(Sender: TObject; var Done: Boolean);
begin
QueryPerformanceCounter(StartCount); //Zeit0
Form1.Render;
QueryPerformanceCounter(EndCount); //Zeit1
Speedfactor := ((EndCount - StartCount) /Frequency) * Scalefactor //(Zeit1 - Zeit0) / Frequenz
[...]
end;
</pascal>

Man hat nun den Speedfactor, den man mit sämtlichen Bewegungen multipliziert. Und schon hat man eine einfache Umsetzung von Timebased movement, ohne sich über Physik Gedanken machen zu müssen.

== Links ==
*[http://www.delphigl.com/script/do_show.php?name=bombman2&action=2 Bomberman DGL-Tutorial]