2007-09-24T00:21:23Z

Deathball: /* GL_FRAMEBUFFER_EXT */

<div align="center">
{|{{Prettytable}}
|widht="80%"|<div style="color:#F09000;font-size:125%"><center>'''Hinweis:''' Dieser Artikel wird gerade Offline bearbeitet!<br>
Bitte haben Sie etwas Geduld und nehmen Sie keine Änderungen vor, bis der Artikel hochgeladen wurde.<br>
[[:Kategorie:Offline in Bearbeitung|(weitere Artikel)]]</center></div>
|width="30%"|[[Bild:WIP Offline.jpg|right|100px]]
|}
</div>
<includeonly> [[Kategorie:Offline in Bearbeitung]] </includeonly>

==GL_FRAMEBUFFER_EXT==
===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
s: GlEnum;
begin
s := 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_DUPLICATE_ATTACHMENT_EXT:
raise Exception.Create('Duplicate 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('Framebuffer 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, @fmo);
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_ATTATCHMENT 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, @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 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 Framebufferobject

2007-09-24T00:03:15Z

Deathball: Die Seite wurde neu angelegt: <div align="center"> {|{{Prettytable}} |widht="80%"|<div style="color:#F09000;font-size:125%"><center>'''Hinweis:''' Dieser Artikel wird gerade Offline bearbeitet!<br> ...

glOrtho

2006-08-28T16:49:03Z

Deathball: /* Beschreibung */

{{Bildwunsch|Ein Objekt (z.B. Würfel) in Orthogonaler und Perspektivischer Projektion vergleichen.}}
= glOrtho =

== Name ==
'''glOrtho''' - aktiviert einen orthogonalen 2D-Rendermodus <br>

== Delphi-Spezifikation ==
procedure '''glOrtho'''(''left'', ''right'', ''bottom'', ''top'', ''znear'', ''zfar'' : double); <br>

== Parameter ==
{| border=1 rules=all
! '''left, right, bottom, top'''
| Definieren die 4 [[Clipping Plane]]s.
|-
! '''znear, zfar'''
| Setzen die Nah- und Fern- Clippingplane. Wenn die Fläche hinter dem User sein soll müssen die Angaben negativ sein.
|}

== Beschreibung ==
'''glOrtho''' erstellt eine Matrix für Parallel-Projektion. Die aktuelle Matrix wird dabei mit der neu erstellten Matrix multipliziert. Das bedeutet, wenn '''M''' die aktuelle und '''O''' die orthogonale Matrix ist, ergibt sich die neue Matrix aus: '''M := M*O'''

Benutzen Sie [[glPushMatrix]] und [[glPopMatrix]] um den aktuellen [[Matrixstack]] zu speichern und zu laden.

Die beiden Punkte (''left, bottom, -near'') und (''right, top, -near'') befinden sich auf der Nah-[[Clipping Plane]] und werden auf die linke-untere und rechte-obere Ecke des Fensters gemappt/abgebildet. Dabei wird die Position des Auges an Position (0,0,0) angenommen. ''-far'' bestimmt die Position der Fernen-[[Clipping Plane]]. Beide Ebenen, die Nahe und die Ferne Schnittebene (Clipping Plane), können negative Werte annehmen.

<div align="center"> Die erstellte Matrix hat die Form: [[Bild:GlOrtho_Matrix.png]]</div>

mit ''f'' = ''zFar'', ''n'' = ''zNear''<br>
''l'' = ''left'','' r'' = ''right''<br>
''t'' = ''top'', ''b'' = ''bottom''<br>

'''glOrtho''' schaltet OpenGL praktisch in einen 2D-Modus, wo die Z-Koordiante keine Rolle mehr im Bezug auf die letztendliche Größe eines Objektes hat (weit entfernte Objekte (mit hoher Z-Koordinate) werden genau so groß gezeichnet, wie Nahe.) <br>
Damit dient die Z-koordiante nur noch zur "Anordnung"" von Vorder- und Hintergründen auf der 2D-Zeichenfläche.

[[Bild:Orthomode_Quads.jpg|thumb|left|300px|Quads an verschiedenen Stellen auf der X-Achse im Orthomodus]]
[[Bild:GluPerspective_Quads_X.jpg|thumb|right|300px|''Zum Vergleich:'' Quads an verschiedenen Stellen der X-Achse im perspektivischen Modus]]
<br>
[[Bild:Orthomode_Quads.jpg|thumb|left|300px|die gleichen Quads mit veränderten Positionen auf der Z-Achse im orthogonalen Modus]]
[[Bild:GluPerspective_Quads_Z.jpg|thumb|right|300px|''Zum Verlgeich:'' Die gleiche Reihe wie ''oben'', nur mit veränderten Positionen auf der Z-Achse, wieder im perspektivischen Modus]]

<br> <br> <br> <br> <br> <br> <br> <br> <br>

''Objekte die einen kleineren Z-Koordinate als ''znear'' bzw. einen größeren als ''zfar'' haben, werden nicht gezeichnet.''

== Fehlermeldungen ==
* '''GL_INVALID_VALUE''' wird generiert wenn zNear gleich zFar, left gleich right oder top gleich bottom ist.

* '''GL_INVALID_OPERATION''' wird generiert wenn '''glOrtho''' innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Werterückgaben ==
[[glGet]] mit Token [[glGet#GL_MATRIX_MODE|GL_MATRIX_MODE]]<br>
[[glGet]] mit Token [[glGet#GL_MODELVIEW_MATRIX|GL_MODELVIEW_MATRIX]]<br>
[[glGet]] mit Token [[glGet#GL_PROJECTION_MATRIX|GL_PROJECTION_MATRIX]]<br>
[[glGet]] mit Token [[glGet#GL_TEXTURE_MATRIX|GL_TEXTURE_MATRIX]]

== Siehe auch ==
[[glFrustum]], [[glMatrixMode]], [[glMultMatrix]], [[glPushMatrix]], [[glViewport]], [[gluPerspective]]

[[Kategorie:GL|Ortho]]

glOrtho

2006-08-28T16:48:39Z

Deathball: /* Beschreibung */

{{Bildwunsch|Ein Objekt (z.B. Würfel) in Orthogonaler und Perspektivischer Projektion vergleichen.}}
= glOrtho =

== Name ==
'''glOrtho''' - aktiviert einen orthogonalen 2D-Rendermodus <br>

== Delphi-Spezifikation ==
procedure '''glOrtho'''(''left'', ''right'', ''bottom'', ''top'', ''znear'', ''zfar'' : double); <br>

== Parameter ==
{| border=1 rules=all
! '''left, right, bottom, top'''
| Definieren die 4 [[Clipping Plane]]s.
|-
! '''znear, zfar'''
| Setzen die Nah- und Fern- Clippingplane. Wenn die Fläche hinter dem User sein soll müssen die Angaben negativ sein.
|}

== Beschreibung ==
'''glOrtho''' erstellt eine Matrix für Parallel-Projektion. Die aktuelle Matrix wird dabei mit der neu erstellten Matrix multipliziert. Das bedeutet, wenn '''M''' die aktuelle und '''O''' die orthogonale Matrix ist, ergibt sich die neue Matrix aus: '''M := M*O'''

Benutzen Sie [[glPushMatrix]] und [[glPopMatrix]] um den aktuellen [[Matrixstack]] zu speichern und zu laden.

Die beiden Punkte (''left, bottom, -near'') und (''right, top, -near'') befinden sich auf der Nah-[[Clipping Plane]] und werden auf die linke-untere und rechte-obere Ecke des Fensters gemappt/abgebildet. Dabei wird die Position des Auges an Position (0,0,0) angenommen. ''-far'' bestimmt die Position der Fernen-[[Clipping Plane]]. Beide Ebenen, die Nahe und die Ferne Schnittebene (Clipping Plane), können negative Werte annehmen.

<div align="center"> Die erstellte Matrix hat die Form: [[Bild:GlOrtho_Matrix.png]]</div>

mit ''f'' = ''zFar'', ''n'' = ''zNear''<br>
''l'' = ''left'','' r'' = ''right''<br>
''t'' = ''top'', ''b'' = ''bottom''<br>

'''glOrtho''' schaltet OpenGL praktisch in einen 2D-Modus, wo die Z-Koordiante keine Rolle mehr im Bezug auf die letztendliche Größe eines Objektes hat (weit entfernte Objekte (mit hoher Z-Koordinate) werden genau so groß gezeichnet, wie Nahe.) <br>
Damit dient die Z-koordiante nur noch zur "Anordnung"" von Vorder- und Hintergründen auf der 2D-Zeichenfläche.

[[Bild:Orthomode_Quads.jpg|thumb|left|300px|Quads an verschiedenen Stellen auf der X-Achse im Orthomodus]]
[[Bild:GluPerspective_Quads_X.jpg|thumb|right|300px|''Zum Vergleich:'' Quads an verschiedenen Stellen der X-Achse im perspektivischen Modus]]
<br>
[[Bild:Orthomode_Quads.jpg|thumb|left|300px|die gleichen Quads mit veränderten Positionen auf der Z-Achse im orthogonalen Modus]]
[[Bild:GluPerspective_Quads_Z.jpg|thumb|right|300px|''Zum Verlgeich:'' Die gleiche Reihe wie ''oben'', nur mit veränderten Positionen auf der Z-Achse, wieder im perspektivischen Modus]]

<br> <br> <br> <br> <br> <br> <br> <br> <br> <br> <br>

''Objekte die einen kleineren Z-Koordinate als ''znear'' bzw. einen größeren als ''zfar'' haben, werden nicht gezeichnet.''

== Fehlermeldungen ==
* '''GL_INVALID_VALUE''' wird generiert wenn zNear gleich zFar, left gleich right oder top gleich bottom ist.

* '''GL_INVALID_OPERATION''' wird generiert wenn '''glOrtho''' innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Werterückgaben ==
[[glGet]] mit Token [[glGet#GL_MATRIX_MODE|GL_MATRIX_MODE]]<br>
[[glGet]] mit Token [[glGet#GL_MODELVIEW_MATRIX|GL_MODELVIEW_MATRIX]]<br>
[[glGet]] mit Token [[glGet#GL_PROJECTION_MATRIX|GL_PROJECTION_MATRIX]]<br>
[[glGet]] mit Token [[glGet#GL_TEXTURE_MATRIX|GL_TEXTURE_MATRIX]]

== Siehe auch ==
[[glFrustum]], [[glMatrixMode]], [[glMultMatrix]], [[glPushMatrix]], [[glViewport]], [[gluPerspective]]

[[Kategorie:GL|Ortho]]

Datei:GluPerspective Quads Z.jpg

2006-08-28T16:42:12Z

Deathball: Reihe von Quads mit unterschiedlicher Entfernung (Position auf der Z-Achse) im perspektivischen Modus.

Reihe von Quads mit unterschiedlicher Entfernung (Position auf der Z-Achse) im perspektivischen Modus.

glOrtho

2006-08-28T16:08:38Z

Deathball: /* Beschreibung */

{{Bildwunsch|Ein Objekt (z.B. Würfel) in Orthogonaler und Perspektivischer Projektion vergleichen.}}
= glOrtho =

== Name ==
'''glOrtho''' - aktiviert einen orthogonalen 2D-Rendermodus <br>

== Delphi-Spezifikation ==
procedure '''glOrtho'''(''left'', ''right'', ''bottom'', ''top'', ''znear'', ''zfar'' : double); <br>

== Parameter ==
{| border=1 rules=all
! '''left, right, bottom, top'''
| Definieren die 4 [[Clipping Plane]]s.
|-
! '''znear, zfar'''
| Setzen die Nah- und Fern- Clippingplane. Wenn die Fläche hinter dem User sein soll müssen die Angaben negativ sein.
|}

== Beschreibung ==
'''glOrtho''' erstellt eine Matrix für Parallel-Projektion. Die aktuelle Matrix wird dabei mit der neu erstellten Matrix multipliziert. Das bedeutet, wenn '''M''' die aktuelle und '''O''' die orthogonale Matrix ist, ergibt sich die neue Matrix aus: '''M := M*O'''

Benutzen Sie [[glPushMatrix]] und [[glPopMatrix]] um den aktuellen [[Matrixstack]] zu speichern und zu laden.

Die beiden Punkte (''left, bottom, -near'') und (''right, top, -near'') befinden sich auf der Nah-[[Clipping Plane]] und werden auf die linke-untere und rechte-obere Ecke des Fensters gemappt/abgebildet. Dabei wird die Position des Auges an Position (0,0,0) angenommen. ''-far'' bestimmt die Position der Fernen-[[Clipping Plane]]. Beide Ebenen, die Nahe und die Ferne Schnittebene (Clipping Plane), können negative Werte annehmen.

<div align="center"> Die erstellte Matrix hat die Form: [[Bild:GlOrtho_Matrix.png]]</div>

mit ''f'' = ''zFar'', ''n'' = ''zNear''<br>
''l'' = ''left'','' r'' = ''right''<br>
''t'' = ''top'', ''b'' = ''bottom''<br>

'''glOrtho''' schaltet OpenGL praktisch in einen 2D-Modus, wo die Z-Koordiante keine Rolle mehr im Bezug auf die letztendliche Größe eines Objektes hat (weit entfernte Objekte (mit hoher Z-Koordinate) werden genau so groß gezeichnet, wie Nahe.) <br>
Damit dient die Z-koordiante nur noch zur "Anordnung"" von Vorder- und Hintergründen auf der 2D-Zeichenfläche.

[[Bild:Orthomode_Quads.jpg|thumb|left|300px|Quads an verschiedenen Stellen auf der X-Achse im Orthomodus]]
[[Bild:GluPerspective_Quads_X.jpg|thumb|right|300px|''Zum Vergleich:'' Quads an verschiedenen Stellen der X-Achse im perspektivischen Modus]]

<br> <br> <br> <br> <br>

''Objekte die einen kleineren Z-Koordinate als ''znear'' bzw. einen größeren als ''zfar'' haben, werden nicht gezeichnet.''

== Fehlermeldungen ==
* '''GL_INVALID_VALUE''' wird generiert wenn zNear gleich zFar, left gleich right oder top gleich bottom ist.

* '''GL_INVALID_OPERATION''' wird generiert wenn '''glOrtho''' innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Werterückgaben ==
[[glGet]] mit Token [[glGet#GL_MATRIX_MODE|GL_MATRIX_MODE]]<br>
[[glGet]] mit Token [[glGet#GL_MODELVIEW_MATRIX|GL_MODELVIEW_MATRIX]]<br>
[[glGet]] mit Token [[glGet#GL_PROJECTION_MATRIX|GL_PROJECTION_MATRIX]]<br>
[[glGet]] mit Token [[glGet#GL_TEXTURE_MATRIX|GL_TEXTURE_MATRIX]]

== Siehe auch ==
[[glFrustum]], [[glMatrixMode]], [[glMultMatrix]], [[glPushMatrix]], [[glViewport]], [[gluPerspective]]

[[Kategorie:GL|Ortho]]

Datei:GluPerspective Quads X.jpg

2006-08-28T16:05:59Z

Deathball: Quads an verschiedenen Stellen der X-Achse im perspektivischen Modus.

Quads an verschiedenen Stellen der X-Achse im perspektivischen Modus.

Datei:Orthomode Quads.jpg

2006-08-28T15:41:22Z

Deathball: Quads an verschiedenen Stellen auf der X-Achse im Orthomodus

Quads an verschiedenen Stellen auf der X-Achse im Orthomodus

Timebased Movement

2006-08-21T18:02:56Z

Deathball: /* Absolute Genauigkeit per Hardware */

== 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 wieviel 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>
var
[...]
Freq, 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(Freq) then
raise Exception.create('Kein Hardware Timer vorhanden');
QueryPerformanceFrequency(Freq); //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) / Freq) * Scalefactor //(Zeit1 - Zeit0) / Frequenz
[...]
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>

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

Tutorial Renderpass

2006-02-01T16:33:21Z

Deathball: /* Die Welt ist eine (Matt-)Schreibe */

= Renderpass - Die Welt daneben =

== Vorwort ==

Greetings!

Nach einer längeren Pause gibt es dann auch mal wieder eine Kleinigkeit von mir. Ich setze an dieser Stelle nicht die bisherige Tutorial-Serie fort, sondern mache diesmal etwas zu einem Spezial-Thema. Mir war gerade privat danach, mit einer anderen Technik rumzuspielen und da dachte ich, ich könnte gleich ein Tutorial drauß machen. Vor allem, weil hier eine Grundlage vermittelt wird, die unter anderem auch dafür eingesetzt werden kann, Objekte zu spiegeln oder für sie einen Schatten zu erzeugen. So kompliziert werden wir das Ganze aber heute gar nicht machen, sondern ich werde nur ein Beispiel geben, wie man mit Hilfe von mehren Render-Durchgängen eine Szene in Echtzeit rendert und auf einen Bildschirm projizieren kann.

Vielleicht kennen einige ja noch die etwas älteren Spiele. Man ist an eine Kamera gegangen und konnte plötzlich das Geschehen auf einem anderen Teil der Karte verfolgen. Der Trick dabei bestand darin, dass man damals die Spielersicht nicht mehr berechnen mußte, sondern nur die Kamera an einen anderen Ort setzte. Dank der modernen Technik können wir jedoch direkt im Spiel eine Szene sehen, die in Echtzeit berechnet wird und irgendwo anders geschieht. Man stelle sich vor, dass man bei einem Auto-Rennen durch eine Stadt fährt und am Himmel ist ein Zeppelin mit einer Holo-Wand. Darauf wird gerade die Ziellinie gezeigt, die die Konkurrenz gerade überfährt! Oder einen Weltraum-Shooter, in dem man gerade einen Angriff auf den Feind fliegt und in dem plötzlich die Warnlampen angehen, ein kleines HUD-Fenster aufspringt und man in Echtzeit verfolgen kann, wie die Wärme-Rakete einem den Antrieb zerfetzt ... ahem *hust* Irgendwie alles nur negative Beispiele, das liegt an mir, nicht an der Technik ;D Viel Spaß beim "Spielen" ;))

== Multiple Render-Passes ==

=== Die Welt, die neben unserer liegt ===

Zunächst sollten wir erstmal klären, was eigentlich ein Render-Pass ist. Moderne Spiele wie Doom3 versprechen bis zu 50 Render-Passes. Damit sind keineswegs Frames gemeint, sondern wie oft eine Szene gerendert wird, bevor sie letztendlich auf den Bildschirm gebracht wird. Was? Wieso sollte man denn eine Szene mehrfach rendern? Nun, dafür kann es unterschiedliche Gründe geben. Nehmen wir doch einfach mal an, wir wollen Multi-Texturing auf einem Rechner mit nur einer Textur-Unit realisieren. Folglich müssen wir zweimal ein Quad mit unterschiedlichen Texturen und Blending zeichnen, um das Ergebnis zu erzielen, welches wir wollen. Genauso kann es sein, dass wir auch andere Dinge mehrfach rendern müssen, um den Effekt zu erzielen, den wir auch wollen. Bei jedem dieser Vorgänge redet man von einem Pass (Durchgang). Man sollte klar dazu sagen, dass jeder zusätzliche Durchgang tödlich für die Geschwindigkeit ist und auch vermieden werden sollte! Wenn es geht...

Aber nun nehmen wir doch mal an, wir wollen viele Bäume rendern, die in der Ferne stehen. Es bietet sich dann an, ein 3D-Modell aus der gebrauchten Perspektive auf eine Textur zu rendern und dann nur noch Quads mit der Textur zu rendern. Ein Quad hat in jedem Fall weniger Polygone als mehrere Bäume und auf die Distanz fällt das nicht mehr auf! Man redet hier übrigens von "Impostern", einem modernen Billboarding-Verfahren, auf das wir sicher aber auch nochmal irgendwann zurückkommen. Wir befassen uns erstmal mit etwas Simplerem ;)

=== Die Welt ist eine (Matt-)Schreibe ===

Stellen wir uns einfach mal eine Szene vor, bei der wir dies gebrauchen könnten! In der Mitte der Szene befindet sich ein Objekt, welches sich bewegt. In unserem Fall habe ich die beliebte Pyramiden-Szene genommen ;) Jeweils links und rechts sind leicht schräg zwei Monitore. Genau in der Mitte leicht oberhalb befindet sich ein weiterer. Auf den Bildschirmen soll nun jeweils die Szene angezeigt werden, und zwar so, wie der Betrachter es auch vor einem Bildschirm sieht. Ich denke, bei dieser Aufgabenstellung würden die meisten schon aussteigen, da zahlreiche Probleme auf einen warten. Die Lösung ist jedoch verblüffend einfach!

Damit sich jeder was drunter vorstellen kann, einmal ein kleines Bild der Szene:

[[Bild:Tutorial_Renderpass_whitescreen.gif]]

Die weißen Flächen sind jeweils unsere Screens. Sehen erschreckend billig aus, gell? ;)

Die Frage, die sich nun stellt ist, wie wir die Szene auf diese weißen Flächen bekommen. Wie wir bereits festgestellt haben, bieten sich hierfür Texturen an, und mit simplestem UV-Mapping haben wir dann auch eine Textur drauf. Mit jeder geladenen Textur ist dies kein Problem, allerdings wollen wir ja eine Szene darauf zeichnen. Nun, dann erzeugen wir sie uns eben, und zwar direkt im Speicher. Gleich nach dem Initialisieren von OpenGL reservieren wir uns ausreichend Speicher für die neue Textur.

<pascal>
procedure CreateScreenTexture;
var pTexData: Pointer;
begin
GetMem(pTexData, 256*256*3);

// Textur generieren und drauf zeigen
glGenTextures(1, @Screen);
glBindTexture(GL_TEXTURE_2D, Screen);

// Daten in den Speicher, Lineares Filtering aktivieren
glTexImage2D(GL_TEXTURE_2D, 0, 3, 256, 256, 0, GL_RGB, GL_UNSIGNED_BYTE, pTexData);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

// Freigeben
FreeMem(pTexData);
end;
</pascal>

Ich denke, dass niemand hier wirklich schockiert sein sollte oder man Unmögliches erwartet. Wir erzeugen im Speicher den Platz, den wir benötigen, erzeugen eine OpenGL Texture, übergeben den reservierten Speicher als Bilddaten, aktivieren gleich noch lineares Filtern (weil’s einfach besser aussieht *g*) und lassen den Pointer dann wieder "frei". Fertig. Schon ist bei uns im Video-Speicher ein Bereich für unsere Textur reserviert und wartet darauf, von uns mißbraucht zu werden :)

=== The first try ===

Nun lautet die Frage, wie wir die Szene auf die Texture bekommen. Man kann es bereits erahnen, dass man die Szene rendern müßte und dann nicht auf dem Bildschirm, sondern auf der Textur ausgeben muß. Der Plan steht also fest! Zunächst rendern wir die Szene einmal auf eine Textur, rendern sie dann nochmal und kleben die "gewonnene" Textur auf die Screens. Zwei Renderpasses. Und wie sonst auch fangen wir erstmal mit etwas Simplem an! Setzen der glClearColor und löschen des Color- und Z-Buffers :)

<pascal>
glClearColor(0.0,0.0,0.0,0);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
</pascal>

Soweit nichts wirklich Neues. Wir behalten im Hintergrund, dass wir für die Textur nur Speicher für 256x256 reserviert haben. Der Grund dafür leuchtet glaube ich auch ein! Viele Grafikkarten unterstützen nicht sehr große Texturen und der Speicher ist rar. Warum also für weiter entfernte Texturen soviel Speicher "verschwenden"? Allerdings werden wir in den meisten Fällen in weitaus höheren Auflösungen auf den Bildschirm rendern. Damit der ganze Bildschirm auch auf die Texture paßt und wir nicht nur einen Teil haben, müssen wir also die Ausgabe auf die Größe der Textur reduzieren. Kinderleicht:

<pascal>
glViewport(0, 0, 256, 256);
</pascal>

Ich denke, man benötigt zum Erraten der Parameter auch keinen Hellseher. Unser Viewport (Ausgabe-Bereich) fängt bei 0/0 an und hört bei 256/256 auf. Wir beachten, dass bei OpenGL der Ursprung nicht oben links ist, sondern unten links. Ich gehe nun nicht näher darauf ein, wie genau die Szene gezeichnet wird. Wir gehen einfach davon aus, dass wir brav die Bildschirme und das Objekt in der Mitte gerendert haben:

[[Bild:Tutorial_Renderpass_viewport.gif]]

Und kein Aufschrei, weil noch die Texturen fehlen! Ich habe der Übersicht halber diese noch nicht eingefügt. Anstatt die Szene nun allerdings auf dem Bildschirm auszugeben, "leiten" wir den Inhalt nun auf die Textur um:

<pascal>
glBindTexture(GL_TEXTURE_2D, Screen);
glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 0, 0, 256, 256, 0);
</pascal>

Mit [[glBindTexture]] weisen wir Screen als "aktuelle Textur" zu. Die darauf folgende Zeile sorgt dann dafür, dass wir auf Screen den momentanen Inhalt des Color-Buffers (ergo unserer Szene) schreiben. Die Parameter sollte man auch nicht weiter verändern, man wird meist damit zu recht kommen. Die beiden 256 erklären sich diesmal wohl auch von selbst.

=== Und ab in die "richtige" Welt ===

Erschreckend einfach oder? Wir haben nun unseren ersten Render-Pass hinter uns und haben die Szene auf einer Textur! Nun beginnen wir unseren zweiten Render-Pass und haben natürlich im Hinterkopf, dass der Color-Buffer noch vom ersten Durchgang voll ist! Also weg damit:

<pascal>
glClearColor(0,0.0,0.3,0);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
</pascal>

Man sollte zur Kenntnis nehmen, dass ich als "Reinigungs-Farbe" einen leicht blauen Schwarzton nehme. Macht die Szene interessanter und man erkennt die Screens anschließend besser ;)

<pascal>
glViewport(0, 0, 800, 600);
</pascal>

Auch diese Zeile sollte nicht vergessen werden, damit wir wieder auf voller Bildschirmbreite rendern. Es bietet sich hier natürlich evtl. an, nicht mit fixen Werten zu arbeiten, sondern jeweils die aktuelle Fensterbreite und Höhe anzugeben.

<pascal>
glBindTexture(GL_TEXTURE_2D,Screen);
RenderScreens;
DrawPyramidScene;
</pascal>

Huch! Das ist alles? Yes... Wir weisen als aktuelle Textur „Screen“ an und zeichnen dann die Bildschirme. Anschließend kommt noch das Objekt in der Mitte dazu. Drawpyramids bindet übrigens seine eigenen Texturen ein, so dass nicht "Screen" verwendet wird. Und fertig ist der zweite Pass und damit auch unsere Szene. OpenGL bringt den Color-Buffer an die Wand, Verzeihung, den Screen ;)

Es kommt nur sehr darauf an, wie wir den ersten Pass durchführen. Ob wir uns mit dem Objekt in der Mitte zufrieden geben…

[[Bild:Tutorial_Renderpass_simple.jpg]]

…oder ob wir uns wie beim zweiten Render-Pass die Screen-Textur krallen und noch zusätzlich die Bildschirme einzeichnen. Wir erhalten dann einen verdammt interessanten rekursiven Effekt:

[[Bild:Tutorial_Renderpass_multiple.jpg]]

=== Und die Perfektion... ===

Damit wäre unser Ziel doch eigentlich erreicht, oder? Dachte ich mir zu diesem Zeitpunkt auch, allerdings habe ich mir noch etwas einfallen lassen. Die Szene ist eigentlich noch einen kleinen Tick zu langweilig! Man kann doch sicherlich noch ein wenig spielen?! Ich dachte mir, dass es doch ganz nett wäre, wenn man die Bildschirme abschalten könnte. Eigentlich nichts Schweres... einfach eine Noise-Textur nehmen und statt dem Screen-Bild drauf zeichnen. Allerdings würde das an sich recht langweilig aussehen, da man nur eine feste "Bildstörung" hätte. Jemand, der mal vor einem Fernseher ohne Empfang gesessen hat, wird jedoch festgestellt haben, dass wir dort durchaus eine Bewegung feststellen können. Was also tun? Einmal meinte einer zu mir ganz cool: "Hey, da nehmen wir einfach viele solcher Noise-Texturen und..." *zack* Schöner Blödsinn ;)

Wir verwenden einfach die Textur-Matrix, um die Texture so zu bewegen, dass der Eindruck entsteht, dass sie sich bewegen würde. Zunächst erhöhen wir eine Variable vor dem ersten Render-Pass:

<pascal>
x:=x+0.01;
</pascal>

Diese Variable verwenden wir dazu, dass der Bildschirm sich immer leicht von oben nach unten bewegt. Es entsteht somit die Illusion des Bildtasters, der das Signal auf die Röhre projiziert. (*hust* Seit wann haben Flachbildschirme Kathoden-Strahler *ggg*... bin echt geil im Märchen erzählen ^__-) Nun haben wir mehr eine einfache Bewegung der Textur von oben nach unten... langweilig! Das Bild soll flackern! Also werden wir chaotisch und erzeugen einfach wilde Zufallswerte, so dass die Textur sehr schnell von links nach rechts springt. Schon ergibt sich folgende Abfrage, bevor ein Screen gerendert wird:

<pascal>
if s1 then
begin
glBindTexture(GL_TEXTURE_2D,screen);
glMatrixMode(GL_TEXTURE);
glLoadIdentity;
glMatrixMode(GL_MODELVIEW);
end
else
begin
glBindTexture(GL_TEXTURE_2D,noise);
glMatrixMode(GL_TEXTURE);
glLoadIdentity;
gltranslate(random(100)/10,x,0);
glMatrixMode(GL_MODELVIEW);
end
</pascal>

In S1 ist gespeichert, welchen Zustand der Screen haben soll. If TRUE (an), dann nehmen wir die Screen-Textur und setzen die Textur-Matrix auf den Standard zurück; falls der Bildschirm aus sein soll, nehmen wir die Noise-Texture und verändern die Textur-Matrix so, wie wir sie brauchen. Das Ganze ist an sich nichts Neues, da dies bereits beim Matrix-Tutorial gezeigt wurde. Allerdings sieht man hier sehr schön, wie man zahlreiche KB für einen Effekt sparen kann, den man so ganz leicht "simulieren" kann ;) (sicherlich wäre es noch besser, die Textur ebenfalls im RAM zu erzeugen!)

Besonders geil hierbei: auch in der Rekursion sind die Bildstörungen enthalten ohne weitere Source! Ist ein Bildschirm aus, sieht man eh nur noch das Rauschen und keine Rekursion! Der Code ist perfekt ;D

[[Bild:Tutorial_Renderpass_noise.jpg]]

== Nachwort ==

So, das war es mal wieder. Das Ganze war sicherlich nicht so ein Monster-Tutorial, wie ihr es sonst von mir gewohnt seid, aber ich denke, dass es trotzdem spannend und unterhaltsam war ;) Mir hat es zumindest sehr viel Spaß gemacht, weil man sich endlich mal kreativ auslassen konnte und ich denke, dass wir inzwischen auch ein Niveau erreicht haben, bei dem man sich den Techniken an sich widmen kann und nicht jeden einzelnen Schritt erklären muss. Laßt mich wissen, wie es Euch gefallen hat und ob ihr alle gut mitgekommen seid. Für Ideen und Kritiken stehe ich wie immer Verfügung!

Btw: Ich frage mich langsam ernsthaft, wie ich auf den Gedanken gekommen bin, dass ein futuristischer Monitor sowas wie eine Störung beim Bildaufbau haben kann. Ich meine... nicht nur technisch! Man wird doch sowas sicherlich in der Zukunft in den Griff bekommen. Interessant ist dabei nur, dass in fast jedem Sciene-Fiction-Film sowas vorkommt. Lauter digitale Screens mit Bildstörungen, die auf analoge Übertragung schließen lassen :-/ . Wer ne Antwort weiß... i-Mehl an mich ;D

Btw2: Dank an Anita für die germanistische Beratung ;)

Viel Spaß beim Experimentieren!

Euer

[[Benutzer:Phobeus|Phobeus]]

{{TUTORIAL_NAVIGATION|[[Tutorial_Abseits_eckiger_Welten]]|[[Tutorial_Selection]]}}

[[Kategorie:Tutorial|NURBS]]