DGL Wiki - Benutzerbeiträge [de]

glBegin

2010-03-26T20:37:52Z

Yogu: /* Name */ Doppelter Verweis auf gleiche Seite im selben Satz entfernt

{{Excellent}}
= glBegin, glEnd =

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

== 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 folgenden 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: 
1. sind moderne Grafikkarten auf die Darstellung von Dreiecken optimiert und 
2. müssen die Polygone bevor sie von den Grafikkarten verwendet werden können, erst in Dreiecke zerlegt werden (siehe [[Triangulation]]). 
Vorallem der letzte Punkt sorgt für niedrige Frameraten im Vergleich zu dreiecksbasierten Strukturen. 
''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]], [[glSecondaryColor]], [[glIndex]], [[glNormal]], [[glFogCoord]], [[glTexCoord]], [[glMultiTexCoord]], [[glVertexAttrib]], [[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.

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:
=== Ab OpenGL-Version 1.3 ===
Zusätzliche Funktionen definiert, welche innerhalb '''glBegin/glEnd''' auftauchen dürfen:
*[[glMultiTexCoord]]
=== Ab OpenGL-Version 1.4 ===
Zusätzliche Funktionen definiert, welche innerhalb '''glBegin/glEnd''' auftauchen dürfen:
*[[glFogCoord]]
*[[glSecondaryColor]]
=== Ab OpenGL-Version 2.0 ===
Zusätzliche Funktionen definiert, welche innerhalb '''glBegin/glEnd''' auftauchen dürfen:
*[[glVertexAttrib]]

== 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]], [[glSecondaryColor]], [[glIndex]], [[glNormal]], [[glFogCoord]], [[glTexCoord]], [[glMultiTexCoord]], [[glVertexAttrib]], [[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]], [[glFogCoordPointer]], [[glTexCoordPointer]], [[glColorPointer]], [[glSecondaryColorPointer]] [[glIndexPointer]], [[glNormalPointer]], [[glVertexPointer]], [[glVertexAttribPointer]], [[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
|-
|
<source lang="pascal">glBegin(GL_TRIANGLES);
glVertex3f(1,0,0);
glVertex3f(0,1,0);
glVertex3f(0,0,1);
glEnd;</source>
|[[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
|-
|
<source lang="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;</source>
|[[Bild:GlBegin_Bsp2.jpg|center]]
|}

== Links ==
http://www.opengl.org/sdk/docs/man/xhtml/glBegin.xml 

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

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

Perlin Noise

2009-04-09T16:07:42Z

Yogu: /* Interpolation */ Hineis korrigiert ;)

{{Excellent}}
Perlin Noise ist ein Fraktal-Algorithmus welcher mit sehr einfachen Formeln komplexe und theoretisch endlose Gebilde berechnen kann. Da Perlin Noise darauf basiert, scheinbar zufällige Funktionen mit weichen Übergängen (die Steigung kann einen gewissen Wert nicht überschreiten) zu benutzen, eignet er sich sehr gut zur Simulation verschiedenster, natürlicher Phänomene wie Beispielsweise:
* Wolken
* Landschaftshöhen- und auch Texturen
* eventuell auch Texturen wie Wasser, Feuer und ähnliches

=Grundlagen=
Perlin Noise basiert auf der Überlagerung von Frequenzen. Bei einer niedrigen Frequenz wird zwischen 2 eher weit voneinander entfernten angegebenen Werten interpoliert. Bei der höchsten (sinnvollen) Frequenz wird für jeden dargestellten Wert (zB jedes Pixel) ein anderer Wert berechnet. Die Werte werden aus Pseudozufallszahlen für eine Positionsangabe gebildet. Die Positionsangabe kann hier eine beliebige Dimension besitzen (beispielsweise 2D für eine Heightmap, 3D für eine Volumentrische Textur, ...). Die Ausgabe ist üblicherweise 1 Wert welcher beliebig interpretiert werden kann.

== Zufallswerte aber wie? ==

Es wird eine Funktion benötigt die für jede Dimension einen Parameter hat und für die gleichen Parameter auch die gleichen Zahlen liefert.
<source lang="pascal">// 1. Dimension
function Werte1D(X:Integer):ErgebnisTyp
// 2.Dimension
function Werte2D(X,Y:Integer):ErgebnisTyp</source>

=== mit einen Array===

Diese Aufgabe kann ein Array erfüllen welches man zuvor mit Zufallswerten gefüllt hat.
also:
<source lang="pascal">
Werte1D:array [0..X_Werte_Max] of ErgebnisTyp;
Werte2D:array [0..X_Werte_Max,0..Y_Werte_Max] of ErgebnisTyp;</source>

=== eigene Zufallsfunktion ===
Ein gängiger Algorithmus sieht beispielsweise so aus:
x := x + Seed;
x := ( x shl 13 ) xor x;
rand := 1 - ( (x * (x * x * 15731 + 789221) + 1376312589) and $7fffffff) / 1073741824;
Rand liefert hier einen Wert für eine 1 Dimensionale Positionsangabe (X - Ganzzahl) einen Wert zwischen -1 und 1. Für 2 Dimensionen könnte dieser Code folgendermaßen erweitert werden:
n := x + y * 57 + Seed;
n := ( n shl 13 ) xor n;
rand := 1 - ( (n * (n * n * 15731 + 789221) + 1376312589) and $7fffffff) / 1073741824;
im weiteren wird diese Funktionalität mit Random( Pos ) bzw. Random( PosX, PosY ) verwendet.

==[[Interpolation]]==

Zwischen den Werten aus dem Array versucht man nun mit einer [[Interpolation]] schöne Übergänge zu schaffen. Am schnellsten ist die lineare [[Interpolation]], jedoch kann durch einen Trick auch eine Sinus artige [[Interpolation]] sehr schnell ablaufen. Auf den folgenden Bildern sieht man links linear [[Interpolation|interpolierte]] Höhenwerte und auf der rechten seite eine Sinus/Cosinus artige [[Interpolation]]. Die größern Punkte entsprechen den im Array abgespeicherten Zufallswerten.

[[Bild:Interpolation.png|center]]

Die [[Interpolation]]s funktion muss zunächst einmal die beiden zu interpolierenden Werte entgegen nehmen. Zusätzlich muss noch durch mindestens einen weiteren Parameter klar werden, welche Position (im obrigen Bild X) den gesuchte Wert haben soll.

Wäre einem die Ausführgeschwindigkeit egal, könnten die beiden Interpolations Funktionen folgerndermaßen aussehen:

<source lang="pascal">//Hinweis: nicht getestet

function InterpoliereLinear(Wert1, Wert2, FaktorWert1: Real): Real;
// Lineare Interpolation von zwei Werten
// FaktorWert1 muss zwischen 0 und 1 liegen
begin
result := Wert1*FaktorWert1 + Wert2*(1-FaktorWert1);
end;

function InterpoliereCos(Wert1, Wert2, FaktorWert1: Real): Real;
// Cosinus/Sinus artige Interpolation von zwei werten;
// FaktorWert muss zwischen 0 und 1 liegen
begin
result := Wert1*((cos(pi/2*FaktorWert1)+1)/2) + Wert2*(1-(cos(pi/2*FaktorWert1)+1)/2)
end;</source>

Jedoch möchte man meistens möglichst schnelle Berechnungen haben. Besonders die Sinus und Cosinus Funktionen können unter Umständen zum Problem werden. Um trotzdem Sinuns- und Cosinus-Interpolation zu erzeugen kann man im Vorraus sich ein Array mit Interpolationswerten anlegen. Da Rechner schneller mit Integerwerten als mit Gleitkommerwerten rechnen werden wir im folgenden Beispiel erstere verwenden.

<source lang="pascal">

var
Interpolation:array [0..Interpolation_Bereich-1]of Integer;
//Interpoaltions_Bereich ist legt die Maximale Anzahl an Punkten fest,
// die für zwei Interpolationswerte ermittelt werden können(inklusive Randpunkte).

const
Interpolation_Max = 1000 // * entspricht dem Wert 1.000;
// * je höher dieser Wert deso genauer das Ergebnis.
// * je höher dieser Wert ist deso niedriger müssen
// die Interpolationswerte sein

procedure BeimStart;
begin
{..}
// Im Interpolations Array werden mit den Werten die von Interpolation_Max bis 0 gehen gefüllt.
// wobei Interpolation[0] = Interpolation_Max ist
// und Interploation[high(Interpolation)] = 0 ist
for i := 0 to high(Interpolation) do Interpolation[I] := round((cos(pi/(Interpolation_Bereich-1)*i)+1)/2*Interpolation_Max);
{..}
end;

function Interpoliere(Wert1, Wert2: Integer; Nr, Von: Integer): Integer;
// Interpoliert zwischen 2 Werten
// Nr ist gibt den Punkt an den man ermitteln möchte. Von die Anzahl der Interpolations schrite
var
Wert1_Faktor:Integer;
begin
if Nr > Von then raise ERangeError.CreateFmt('Nr Wert %d nicht in 0..%d',[Nr,Von-1]);
if Von > Interpolations_Bereich raise ERangeError.CreateFmt('Von Wert %d nicht in 0..%d',[0,-1]);
Wert1_Faktor := Interpolation[(Interpolation_Bereich* Nr)div Von];
result := (Wert1*Wert1_Faktor) div Interpolation_Max
+ (Wert2*(1000 - Wert1_Faktor)) div Interpolation_Max;
end;</source>

Dies wäre die [[Interpolation]] für eine 1 Dimensionale Positionsangabe. Natürlich müssen aber auch die anderen Dimensionen [[Interpolation|interpoliert]] werden. Dies kann aber (wenn gewünscht) ebenfalls mit mehreren [[Interpolation]]en von 2 Werten erfolgen
PosX = Ganzzahl( Position.x )
PosY = Ganzzahl( Position.y )
X1 = Interpoliere( Random( PosX, PosY ), Random( PosX, PosY + 1 ), Nachkommateil( Position.y ) )
X2 = Interpoliere( Random( PosX + 1, PosY), Random( PosX + 1, PosY + 1, Nachkommateil( Position.y ) )
Ergebnis = Interpoliere( X1, X2, Nachkommateil( Position.x ) )

=Algorithmus=
Mit den oben beschriebenen Funktionen ist der Algorithmus recht schnell zu machen.

==Die Parameter==
Der Perlin Noise Algorithmus erhält üblicherweise folgende Parameter:
*Double: Position (Die Position wird bereits entsprechend skaliert)
*Double: Persistenz (wie stark ist der Einfluss der höheren Frequenzen)
*Wertebereich: Double: Min, Double: Max
*Integer: Rechentiefe (Detailgrad)
*Gegebenenfalls Double: Frequenzfaktor (oder Standard auf 2)
Die Laufzeit für einen berechneten Wert beträgt [[O-Notation|O]]( n ) wobei n die Rechentiefe angibt.

==Überlagerung der Frequenzen==
Es wird für jeden Detailgrad ein Wert berechnet. Da Perlin Noise für einen einzelnen Wert kaum Sinn macht und im Normalfall für mehrere nebeneinander liegende Positionen ein Wert berechnet wird, kann man auch von Frequenzbändern sprechen. Der Code könnte beispielsweise so aussehen:
Wert = 0
Für jeden Detailgrad
Wert = Wert + InterpolierterWert( Position * Frequenz )
Frequenz = Frequenz * Frequenzfaktor
Wie hier unschwer zu erkennen ist werden die Werte addiert (also überlagert).

[[Bild:PerlinUeberlagerung.png|center|framed|''Abb.1: Frequenzbänder für 200 Werte (Pixel).'' 
''Frequenzfaktor = 2; Persitenz = 0.5;'' 
''Links oben: Frequenz 0.01 (Einheit = Pixel)'' 
''Rechts oben: Frequenz 0.02'' 
''Links unten: Frequenz 0.04'' 
''Rechts unten: überlagerte (addierte) Frequenzbänder (für die ersten 3 Detailgrade)'']]

==Rechentiefe==
Die Rechentiefe gibt an wie hoch der Detailgrad sein soll. In Abbildung 1 (siehe Frequenzen) wurde beispielsweise eine Rechentiefe von 3 verwendet. Bei einem 2 Dimensionalen Perlin Noise dürfte dies jedoch deutlichere Unterschiede zeigen (siehe Abbildung 2).

[[Bild:PerlinTiefe.png|center|framed|''Abb. 2: Unterschiedliche Rechentiefen.'' 
''Frequenzfaktor = 2; Persitenz = 0.5;'' 
''Links oben: Rechentiefe 1'' 
''Rechts oben: Rechentiefe 2'' 
''Links unten: Rechentiefe 3'' 
''Rechts unten: Rechentiefe 4'']]

==Persistenz==
Die Persistenz gibt an wie stark die höheren Frequenzbänder Einfluss auf das Ergebnis haben sollen. Hierfür erweitern wir den unter '''Überlagerung der Frequenzen''' angegebenen Code:
Wert = 0
Faktor = 1
Für Detailgrad = 1 bis Rechentiefe
Wert = Wert + InterpolierterWert( Position * Frequenz ) * Faktor
Frequenz = Frequenz * Frequenzfaktor
Faktor = Faktor * Persistenz

[[Bild:PerlinPersistenz.png|center|framed|
''Abb. 3: Unterschiedliche Persistenzen.'' 
''Frequenzfaktor = 2; Rechentiefe = 5'' 
''Links oben: Persistenz 0.2'' 
''Rechts oben: Persistenz 0.4'' 
''Links unten: Persistenz 0.6'' 
''Rechts unten: Persistenz 0.8'']]

==Der Wertebereich==
Bisher wurden zwar in den Bildern die Werte korrekt dargestellt, jedoch wurde noch nicht erklärt wie man zu diesen Werten kommt. Wir möchten nun den Code welcher unter Persistenz angegeben wurde so modifizieren, das er Werte für den Wertebereich [Min|Max] liefert. Betrachten wir vorerst was wir alles verwenden:
*InterpolierterWert( Position * Frequenz ): liefert einen Wert im Bereich [-1|1]
*Faktor: zu Beginn 1, wird bei jeden Durchlauf mit Persistenz multipliziert
*Frequenz und Frequenzfaktor: spielen für die Amplitude keine Rolle
Der Gesamtfaktor lässt sich recht einfach berechnen:
Faktor = 1
GesFaktor = 0
Für Deteilgrad = 1 bis Rechentiefe
GesFaktor = GesFaktor + Faktor
Faktor = Faktor * Persistenz
Mit dem errechneten Gesamtfaktor wissen wir nun, das die Funktion einen Wert im Bereich

[-GesFaktor|+GesFaktor] liefert. Nun brauchen wir nur noch die Amplitude skalieren und einen entsprechenden Offset für das Minimum addieren. Dies sieht im Endeffekt so aus:

Initialisierung:
Bereich = Max - Min;
Offset = Min + Bereich * 0.5;
GesFaktor = 0;
Faktor = 2;

für 1 bis Rechentiefe
GesFaktor += Faktor
Faktor = Faktor * Persistenz

Tiefe_1_Amplitude = Bereich / GesFaktor

Berechnung eines Wertes:
Wert = 0
Faktor = Tiefe_1_Amplitude
Frequenz = 1
Für Detailgrad = 1 bis Rechentiefe
Wert = Wert + InterpolierterWert( Position * Frequenz ) * Faktor
Frequenz = Frequenz * Frequenzfaktor
Faktor = Faktor * Persistenz

Wert = Wert + Offset

= Weiterführendes =
== Einsatzgebiete ==
Neben der Generierung von Texturen und [[Heightmap]]s - welche von den Grafiken und Quellcodes in diesem Artikel bevorzugt behandelt wurden - gibt es natürlich noch andere Einsatzgebiete. Einige davon sind:
* Animation, also gehen, Mimik oder jede andere Form von Bewegung kann durch Perlin Noise abwechslungsreicher und somit etwas "menschlicher" gestaltet werden. Der Erfinder Ken Perlin hat hierfür auf seiner [http://mrl.nyu.edu/~perlin/ Homepage] ein paar gute Beispiele.
* Modifikation von Meshes: was bei [[Heightmap]]s am offensichtlichesten ist kann man auch auf eine Kugel anwenden um einen wunderbar unregelmäßigen, aber dennoch realistisch wirkenden Stein, Planeten oder einen Kometen daraus zu machen.
* Denkbar wäre die Verwendung von Perlin Noise natürlich auch für verschiedenste Umwelteinflüsse wie Wind (was sich sowohl in Animationen als auch Geräuschlautstärke auswirken kann), aber natürlich auch für künstliche Einflüsse wie Börsenkurse in einem Strategiespiel.
* Prozedurale Texturen (u.a. Holz-, Stein-, oder Marmor-Oberflächen) können gut mit Perlin Noise und einigen Zusatzfunktionen erzeugt werden.

== Erweiterungen ==
Perlin Noise kann (wie nahezu jeder andere Algorithmus auch) nach eigenen Wünschen modifiziert werden. Häufige Modifikationen sind:
* Tilebare Texturen erstellen, also Texturen welche links und rechts - und ggf. auch oben und unten - exakt gleich aussehen. Dieses Problem wird in [http://www.delphigl.com/forum/viewtopic.php?t=3859&postdays=0&postorder=asc&start=15 diesem DGL-Forenthread (ab Seite 2)] etwas näher behandelt.
* Nachbearbeitung der Ausgabewerte. Hier können wir das endgültige Resultat noch sehr stark verändern. Denkbar wäre hier beispielsweise, dass wir die Unterwasser und über Wasser - Landschaft ganz unterschiedlich skalieren. Das eindrucksvollste Beispiel hierfür dürfte jedoch ein Algorithmus für eine [[Himmel]]stextur sein, welcher [http://freespace.virgin.net/hugo.elias/models/m_clouds.htm hier] zu finden ist. Dieser Algorithmus verwendet einfaches Perlin Noise, modifiziert jedoch die Ausgabewerte mit einer Exponentialfunktion, wodurch eine (meines Erachtens) eindrucksvolle Wolkendecke entsteht. Das endgültige Ergebnis des Algorithmus beinhaltet natürlich noch etwas mehr als diese einfache Exponentialfunktion, jedoch könnte man auch dies im weiteren Sinne als Modifikation der Ausgabewerte sehen.

== Verwandte Themen ==
Die Dekomprimierung von JPEG-Bildern basiert auf der Überlagerungen von Cosinus-Schwingungen einer vorgegebenen Frequenz und einer (von Bild zu Bild) variierenden Amplitude. Diese Überlagerung ist sehr ähnlich der Frequenzüberlagerung beim Perlin Noise. Der Unterschied ist natürlich, dass bei JPEG Cosinus Schwingungen verwendet werden und beim Perlin Noise zufällige Werte welche [[Interpolation|interpoliert]] werden.

Die Komprimierung von JPEG-Bildern bildet nun das Gegenteil der Überlagerung von Cosinus-Schwingungen, also der Berechnung der Amplituden der einzelnen Frequenzen. Derartige Berechnungen basieren alle auf der Fourier Transformation.

Also wenn ihr nun verstanden habt wozu die Überlagerung von verschiedenen Frequenzbändern in der Lage ist (wofür dieser Artikel hoffentlich hilfreich war), euch diverse Themen der Mathematik wie integrieren, differenzieren und vor allem Regression nicht allzu sehr abschrecken und ihr immer schon mal wissen wolltet wie derartige Bildkompression oder die Frequenzbalken eurer Audiowidergabe entstehen, wäre wohl nun ein (neuer?) Anlauf vielversprechend.

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

Perlin Noise

2009-04-09T16:06:55Z

Yogu: /* Interpolation */ Rückgabewerte für "InterpoliereLinear" und "InterpoliereCos" hinzugefügt

{{Excellent}}
Perlin Noise ist ein Fraktal-Algorithmus welcher mit sehr einfachen Formeln komplexe und theoretisch endlose Gebilde berechnen kann. Da Perlin Noise darauf basiert, scheinbar zufällige Funktionen mit weichen Übergängen (die Steigung kann einen gewissen Wert nicht überschreiten) zu benutzen, eignet er sich sehr gut zur Simulation verschiedenster, natürlicher Phänomene wie Beispielsweise:
* Wolken
* Landschaftshöhen- und auch Texturen
* eventuell auch Texturen wie Wasser, Feuer und ähnliches

=Grundlagen=
Perlin Noise basiert auf der Überlagerung von Frequenzen. Bei einer niedrigen Frequenz wird zwischen 2 eher weit voneinander entfernten angegebenen Werten interpoliert. Bei der höchsten (sinnvollen) Frequenz wird für jeden dargestellten Wert (zB jedes Pixel) ein anderer Wert berechnet. Die Werte werden aus Pseudozufallszahlen für eine Positionsangabe gebildet. Die Positionsangabe kann hier eine beliebige Dimension besitzen (beispielsweise 2D für eine Heightmap, 3D für eine Volumentrische Textur, ...). Die Ausgabe ist üblicherweise 1 Wert welcher beliebig interpretiert werden kann.

== Zufallswerte aber wie? ==

Es wird eine Funktion benötigt die für jede Dimension einen Parameter hat und für die gleichen Parameter auch die gleichen Zahlen liefert.
<source lang="pascal">// 1. Dimension
function Werte1D(X:Integer):ErgebnisTyp
// 2.Dimension
function Werte2D(X,Y:Integer):ErgebnisTyp</source>

=== mit einen Array===

Diese Aufgabe kann ein Array erfüllen welches man zuvor mit Zufallswerten gefüllt hat.
also:
<source lang="pascal">
Werte1D:array [0..X_Werte_Max] of ErgebnisTyp;
Werte2D:array [0..X_Werte_Max,0..Y_Werte_Max] of ErgebnisTyp;</source>

=== eigene Zufallsfunktion ===
Ein gängiger Algorithmus sieht beispielsweise so aus:
x := x + Seed;
x := ( x shl 13 ) xor x;
rand := 1 - ( (x * (x * x * 15731 + 789221) + 1376312589) and $7fffffff) / 1073741824;
Rand liefert hier einen Wert für eine 1 Dimensionale Positionsangabe (X - Ganzzahl) einen Wert zwischen -1 und 1. Für 2 Dimensionen könnte dieser Code folgendermaßen erweitert werden:
n := x + y * 57 + Seed;
n := ( n shl 13 ) xor n;
rand := 1 - ( (n * (n * n * 15731 + 789221) + 1376312589) and $7fffffff) / 1073741824;
im weiteren wird diese Funktionalität mit Random( Pos ) bzw. Random( PosX, PosY ) verwendet.

==[[Interpolation]]==

Zwischen den Werten aus dem Array versucht man nun mit einer [[Interpolation]] schöne Übergänge zu schaffen. Am schnellsten ist die lineare [[Interpolation]], jedoch kann durch einen Trick auch eine Sinus artige [[Interpolation]] sehr schnell ablaufen. Auf den folgenden Bildern sieht man links linear [[Interpolation|interpolierte]] Höhenwerte und auf der rechten seite eine Sinus/Cosinus artige [[Interpolation]]. Die größern Punkte entsprechen den im Array abgespeicherten Zufallswerten.

[[Bild:Interpolation.png|center]]

Die [[Interpolation]]s funktion muss zunächst einmal die beiden zu interpolierenden Werte entgegen nehmen. Zusätzlich muss noch durch mindestens einen weiteren Parameter klar werden, welche Position (im obrigen Bild X) den gesuchte Wert haben soll.

Wäre einem die Ausführgeschwindigkeit egal, könnten die beiden Interpolations Funktionen folgerndermaßen aussehen:

<source lang="pascal">//Hineis: nicht getestet

function InterpoliereLinear(Wert1, Wert2, FaktorWert1: Real): Real;
// Lineare Interpolation von zwei Werten
// FaktorWert1 muss zwischen 0 und 1 liegen
begin
result := Wert1*FaktorWert1 + Wert2*(1-FaktorWert1);
end;

function InterpoliereCos(Wert1, Wert2, FaktorWert1: Real): Real;
// Cosinus/Sinus artige Interpolation von zwei werten;
// FaktorWert muss zwischen 0 und 1 liegen
begin
result := Wert1*((cos(pi/2*FaktorWert1)+1)/2) + Wert2*(1-(cos(pi/2*FaktorWert1)+1)/2)
end;</source>

Jedoch möchte man meistens möglichst schnelle Berechnungen haben. Besonders die Sinus und Cosinus Funktionen können unter Umständen zum Problem werden. Um trotzdem Sinuns- und Cosinus-Interpolation zu erzeugen kann man im Vorraus sich ein Array mit Interpolationswerten anlegen. Da Rechner schneller mit Integerwerten als mit Gleitkommerwerten rechnen werden wir im folgenden Beispiel erstere verwenden.

<source lang="pascal">

var
Interpolation:array [0..Interpolation_Bereich-1]of Integer;
//Interpoaltions_Bereich ist legt die Maximale Anzahl an Punkten fest,
// die für zwei Interpolationswerte ermittelt werden können(inklusive Randpunkte).

const
Interpolation_Max = 1000 // * entspricht dem Wert 1.000;
// * je höher dieser Wert deso genauer das Ergebnis.
// * je höher dieser Wert ist deso niedriger müssen
// die Interpolationswerte sein

procedure BeimStart;
begin
{..}
// Im Interpolations Array werden mit den Werten die von Interpolation_Max bis 0 gehen gefüllt.
// wobei Interpolation[0] = Interpolation_Max ist
// und Interploation[high(Interpolation)] = 0 ist
for i := 0 to high(Interpolation) do Interpolation[I] := round((cos(pi/(Interpolation_Bereich-1)*i)+1)/2*Interpolation_Max);
{..}
end;

function Interpoliere(Wert1, Wert2: Integer; Nr, Von: Integer): Integer;
// Interpoliert zwischen 2 Werten
// Nr ist gibt den Punkt an den man ermitteln möchte. Von die Anzahl der Interpolations schrite
var
Wert1_Faktor:Integer;
begin
if Nr > Von then raise ERangeError.CreateFmt('Nr Wert %d nicht in 0..%d',[Nr,Von-1]);
if Von > Interpolations_Bereich raise ERangeError.CreateFmt('Von Wert %d nicht in 0..%d',[0,-1]);
Wert1_Faktor := Interpolation[(Interpolation_Bereich* Nr)div Von];
result := (Wert1*Wert1_Faktor) div Interpolation_Max
+ (Wert2*(1000 - Wert1_Faktor)) div Interpolation_Max;
end;</source>

Dies wäre die [[Interpolation]] für eine 1 Dimensionale Positionsangabe. Natürlich müssen aber auch die anderen Dimensionen [[Interpolation|interpoliert]] werden. Dies kann aber (wenn gewünscht) ebenfalls mit mehreren [[Interpolation]]en von 2 Werten erfolgen
PosX = Ganzzahl( Position.x )
PosY = Ganzzahl( Position.y )
X1 = Interpoliere( Random( PosX, PosY ), Random( PosX, PosY + 1 ), Nachkommateil( Position.y ) )
X2 = Interpoliere( Random( PosX + 1, PosY), Random( PosX + 1, PosY + 1, Nachkommateil( Position.y ) )
Ergebnis = Interpoliere( X1, X2, Nachkommateil( Position.x ) )

=Algorithmus=
Mit den oben beschriebenen Funktionen ist der Algorithmus recht schnell zu machen.

==Die Parameter==
Der Perlin Noise Algorithmus erhält üblicherweise folgende Parameter:
*Double: Position (Die Position wird bereits entsprechend skaliert)
*Double: Persistenz (wie stark ist der Einfluss der höheren Frequenzen)
*Wertebereich: Double: Min, Double: Max
*Integer: Rechentiefe (Detailgrad)
*Gegebenenfalls Double: Frequenzfaktor (oder Standard auf 2)
Die Laufzeit für einen berechneten Wert beträgt [[O-Notation|O]]( n ) wobei n die Rechentiefe angibt.

==Überlagerung der Frequenzen==
Es wird für jeden Detailgrad ein Wert berechnet. Da Perlin Noise für einen einzelnen Wert kaum Sinn macht und im Normalfall für mehrere nebeneinander liegende Positionen ein Wert berechnet wird, kann man auch von Frequenzbändern sprechen. Der Code könnte beispielsweise so aussehen:
Wert = 0
Für jeden Detailgrad
Wert = Wert + InterpolierterWert( Position * Frequenz )
Frequenz = Frequenz * Frequenzfaktor
Wie hier unschwer zu erkennen ist werden die Werte addiert (also überlagert).

[[Bild:PerlinUeberlagerung.png|center|framed|''Abb.1: Frequenzbänder für 200 Werte (Pixel).'' 
''Frequenzfaktor = 2; Persitenz = 0.5;'' 
''Links oben: Frequenz 0.01 (Einheit = Pixel)'' 
''Rechts oben: Frequenz 0.02'' 
''Links unten: Frequenz 0.04'' 
''Rechts unten: überlagerte (addierte) Frequenzbänder (für die ersten 3 Detailgrade)'']]

==Rechentiefe==
Die Rechentiefe gibt an wie hoch der Detailgrad sein soll. In Abbildung 1 (siehe Frequenzen) wurde beispielsweise eine Rechentiefe von 3 verwendet. Bei einem 2 Dimensionalen Perlin Noise dürfte dies jedoch deutlichere Unterschiede zeigen (siehe Abbildung 2).

[[Bild:PerlinTiefe.png|center|framed|''Abb. 2: Unterschiedliche Rechentiefen.'' 
''Frequenzfaktor = 2; Persitenz = 0.5;'' 
''Links oben: Rechentiefe 1'' 
''Rechts oben: Rechentiefe 2'' 
''Links unten: Rechentiefe 3'' 
''Rechts unten: Rechentiefe 4'']]

==Persistenz==
Die Persistenz gibt an wie stark die höheren Frequenzbänder Einfluss auf das Ergebnis haben sollen. Hierfür erweitern wir den unter '''Überlagerung der Frequenzen''' angegebenen Code:
Wert = 0
Faktor = 1
Für Detailgrad = 1 bis Rechentiefe
Wert = Wert + InterpolierterWert( Position * Frequenz ) * Faktor
Frequenz = Frequenz * Frequenzfaktor
Faktor = Faktor * Persistenz

[[Bild:PerlinPersistenz.png|center|framed|
''Abb. 3: Unterschiedliche Persistenzen.'' 
''Frequenzfaktor = 2; Rechentiefe = 5'' 
''Links oben: Persistenz 0.2'' 
''Rechts oben: Persistenz 0.4'' 
''Links unten: Persistenz 0.6'' 
''Rechts unten: Persistenz 0.8'']]

==Der Wertebereich==
Bisher wurden zwar in den Bildern die Werte korrekt dargestellt, jedoch wurde noch nicht erklärt wie man zu diesen Werten kommt. Wir möchten nun den Code welcher unter Persistenz angegeben wurde so modifizieren, das er Werte für den Wertebereich [Min|Max] liefert. Betrachten wir vorerst was wir alles verwenden:
*InterpolierterWert( Position * Frequenz ): liefert einen Wert im Bereich [-1|1]
*Faktor: zu Beginn 1, wird bei jeden Durchlauf mit Persistenz multipliziert
*Frequenz und Frequenzfaktor: spielen für die Amplitude keine Rolle
Der Gesamtfaktor lässt sich recht einfach berechnen:
Faktor = 1
GesFaktor = 0
Für Deteilgrad = 1 bis Rechentiefe
GesFaktor = GesFaktor + Faktor
Faktor = Faktor * Persistenz
Mit dem errechneten Gesamtfaktor wissen wir nun, das die Funktion einen Wert im Bereich

[-GesFaktor|+GesFaktor] liefert. Nun brauchen wir nur noch die Amplitude skalieren und einen entsprechenden Offset für das Minimum addieren. Dies sieht im Endeffekt so aus:

Initialisierung:
Bereich = Max - Min;
Offset = Min + Bereich * 0.5;
GesFaktor = 0;
Faktor = 2;

für 1 bis Rechentiefe
GesFaktor += Faktor
Faktor = Faktor * Persistenz

Tiefe_1_Amplitude = Bereich / GesFaktor

Berechnung eines Wertes:
Wert = 0
Faktor = Tiefe_1_Amplitude
Frequenz = 1
Für Detailgrad = 1 bis Rechentiefe
Wert = Wert + InterpolierterWert( Position * Frequenz ) * Faktor
Frequenz = Frequenz * Frequenzfaktor
Faktor = Faktor * Persistenz

Wert = Wert + Offset

= Weiterführendes =
== Einsatzgebiete ==
Neben der Generierung von Texturen und [[Heightmap]]s - welche von den Grafiken und Quellcodes in diesem Artikel bevorzugt behandelt wurden - gibt es natürlich noch andere Einsatzgebiete. Einige davon sind:
* Animation, also gehen, Mimik oder jede andere Form von Bewegung kann durch Perlin Noise abwechslungsreicher und somit etwas "menschlicher" gestaltet werden. Der Erfinder Ken Perlin hat hierfür auf seiner [http://mrl.nyu.edu/~perlin/ Homepage] ein paar gute Beispiele.
* Modifikation von Meshes: was bei [[Heightmap]]s am offensichtlichesten ist kann man auch auf eine Kugel anwenden um einen wunderbar unregelmäßigen, aber dennoch realistisch wirkenden Stein, Planeten oder einen Kometen daraus zu machen.
* Denkbar wäre die Verwendung von Perlin Noise natürlich auch für verschiedenste Umwelteinflüsse wie Wind (was sich sowohl in Animationen als auch Geräuschlautstärke auswirken kann), aber natürlich auch für künstliche Einflüsse wie Börsenkurse in einem Strategiespiel.
* Prozedurale Texturen (u.a. Holz-, Stein-, oder Marmor-Oberflächen) können gut mit Perlin Noise und einigen Zusatzfunktionen erzeugt werden.

== Erweiterungen ==
Perlin Noise kann (wie nahezu jeder andere Algorithmus auch) nach eigenen Wünschen modifiziert werden. Häufige Modifikationen sind:
* Tilebare Texturen erstellen, also Texturen welche links und rechts - und ggf. auch oben und unten - exakt gleich aussehen. Dieses Problem wird in [http://www.delphigl.com/forum/viewtopic.php?t=3859&postdays=0&postorder=asc&start=15 diesem DGL-Forenthread (ab Seite 2)] etwas näher behandelt.
* Nachbearbeitung der Ausgabewerte. Hier können wir das endgültige Resultat noch sehr stark verändern. Denkbar wäre hier beispielsweise, dass wir die Unterwasser und über Wasser - Landschaft ganz unterschiedlich skalieren. Das eindrucksvollste Beispiel hierfür dürfte jedoch ein Algorithmus für eine [[Himmel]]stextur sein, welcher [http://freespace.virgin.net/hugo.elias/models/m_clouds.htm hier] zu finden ist. Dieser Algorithmus verwendet einfaches Perlin Noise, modifiziert jedoch die Ausgabewerte mit einer Exponentialfunktion, wodurch eine (meines Erachtens) eindrucksvolle Wolkendecke entsteht. Das endgültige Ergebnis des Algorithmus beinhaltet natürlich noch etwas mehr als diese einfache Exponentialfunktion, jedoch könnte man auch dies im weiteren Sinne als Modifikation der Ausgabewerte sehen.

== Verwandte Themen ==
Die Dekomprimierung von JPEG-Bildern basiert auf der Überlagerungen von Cosinus-Schwingungen einer vorgegebenen Frequenz und einer (von Bild zu Bild) variierenden Amplitude. Diese Überlagerung ist sehr ähnlich der Frequenzüberlagerung beim Perlin Noise. Der Unterschied ist natürlich, dass bei JPEG Cosinus Schwingungen verwendet werden und beim Perlin Noise zufällige Werte welche [[Interpolation|interpoliert]] werden.

Die Komprimierung von JPEG-Bildern bildet nun das Gegenteil der Überlagerung von Cosinus-Schwingungen, also der Berechnung der Amplituden der einzelnen Frequenzen. Derartige Berechnungen basieren alle auf der Fourier Transformation.

Also wenn ihr nun verstanden habt wozu die Überlagerung von verschiedenen Frequenzbändern in der Lage ist (wofür dieser Artikel hoffentlich hilfreich war), euch diverse Themen der Mathematik wie integrieren, differenzieren und vor allem Regression nicht allzu sehr abschrecken und ihr immer schon mal wissen wolltet wie derartige Bildkompression oder die Frequenzbalken eurer Audiowidergabe entstehen, wäre wohl nun ein (neuer?) Anlauf vielversprechend.

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

SwapBuffers

2009-03-31T18:36:00Z

Yogu: Hinweis zu ShowModal eingefügt

= SwapBuffers =

== Name ==
'''SwapBuffers''' - tauscht Back- und Frontbuffer aus.

== Delphi-Spezifikation ==
'''function''' SwapBuffers(''DC'' : HDC) : Boolean;

== Parameter ==
{| border=1 rules=all
! '''DC'''
|Steht für den Device Kontext und bezeichnet die aktuelle Zeichenfläche
|}

== Beschreibung ==
Die Funktion SwapBuffers tauscht Back- und Frontbuffer aus. 
Diese Methode ist essentiell für das [[Doppelpufferung|Doublebuffering]].

== Zugehörige Wertrückgaben ==
Diese Funktion liefert TRUE zurück, wenn der Buffertausch vollzogen werden konnte. Andernfalls wird FALSE zurückgeliefert.

== Funktionalität ==
SwapBuffers funktioniert nicht, wenn ein modales Formular angezeigt wird. In diesem Fall liefert die Funktion FALSE zurück.

== Siehe auch ==
[[Doppelpufferung|Doublebuffering]]

Screenshot

2009-01-24T14:29:07Z

Yogu: /* Speichern im TGA-Format bei Nutzung von SDL */

== Allgemeines zum Screenshot erstellen ==
=== Einleitung ===
Ein '''Screenshot''' ist ein Abbild des aktuellen Bildschirm Inhaltes.

Im Falle von OpenGL greifen wir nicht auf das Fenster zurück sondern auf den [[Framebuffer]]. Neben dem eigentlichen Vorgang des Bilddatenbesorgens ist es meistens auch noch sinnvoll die Daten dem Benutzer verfügbar zu machen. Dies geschieht meistens in Form einer Bild-Datei oder eines Eintrages in der Zwischenablage.

=== Bilddaten besorgen ===
Mit Hilfe des [[glReadPixels]] Befehls kann der [[Framebuffer]] ausgelesen werden. Für einen Screenshot sind meistens die [[RGB]]-Werte interessant. Bei diesen Werten ergibt sich auch schon das erste Problem: OpenGL speichert die Daten in der Reihenfolge Rot Grün Blau, während es in einigen Bildformaten (nämlich denen die auf Bitmaps aufbauen) üblich ist, die Daten in der Reihenfolge Blau Grün Rot zu speichern. Glücklicherweise kann man in aktuellen OpenGL Versionen [[glReadPixels]] anweisen die Daten auch in dieser Reihenfolge zu liefern.

Der [[glReadPixels]] Befehl für neue Grafikkarten könnte in etwa so aussehen:
<pascal>
// ungünstige Reihenfolge Rot Grün Blau
glReadPixels( 0, 0, Breite, Hoehe, GL_RGB, GL_UNSIGNED_BYTE, Daten );
// auf neueren Grafikkarten:
glReadPixels( 0, 0, Breite, Hoehe, GL_BGR, GL_UNSIGNED_BYTE, Daten );
</pascal>

Was die einzelnen Parameter bedeuten, könnt ihr im [[glReadPixels]] Artikel nachlesen. Es sei hier nur gesagt das das letzte Argument der Speicherplatz ist, an dem OpenGL die Daten abspeichern soll (meist ein Pointer z.B. auf ein Array).

=== Hinweis ===
Unter [[SDL]] finden sich die Bilddaten schon in der [[SDL_Surface|Displaysurface]] unter ''pixels''.

== Speichern des Screenshots ==
Die Speicherung der Screenshots ist, sofern man erst einmal die Rohdaten der einzelnen Pixel hat, nicht mehr allzu kompliziert. Da der Computer aber ohne zusätzliche Informationen zu diesen Rohdaten später nichts mehr mit ihnen anfangen könnte, muss man einige zusätzliche Informationen mit in seine Zieldatei schreiben, die oftmals als "Header" bezeichnet werden und Informationen zu Breite, Höhe und "Pixelformat" beinhalten.

=== Speichern im BMP Format ===

Eine BMP-Datei hat einen relativ einfachen Aufbau. Als erstes kommen Header-Informationen (das Zeugs, was die Daten als Bitmap ausweist ;-)), dann FileInfo-Informationen (das, was angibt, wie groß das Bitmap ist) und schließlich die eigentlichen Bilddaten.

Der Header sieht so aus:
<pascal> BITMAPFILEHEADER = packed record
bfType: Word;
bfSize: DWORD;
bfReserved1: Word;
bfReserved2: Word;
bfOffBits: DWORD;
end;

BITMAPINFOHEADER = packed record
biSize: DWORD;
biWidth: Longint;
biHeight: Longint;
biPlanes: Word;
biBitCount: Word;
biCompression: DWORD;
biSizeImage: DWORD;
biXPelsPerMeter: Longint;
biYPelsPerMeter: Longint;
biClrUsed: DWORD;
biClrImportant: DWORD;
end;</pascal>

Nun zur Speicherfunktion für einen Screenshot:
<pascal>procedure ScreenShot(const Name : string);
var F : file;
FileInfo: BITMAPINFOHEADER;
FileHeader : BITMAPFILEHEADER;
pPicData:Pointer;
Viewport : array[0..3] of integer;
begin
//Speicher für die Speicherung der Header-Informationen vorbereiten
ZeroMemory(@FileHeader, SizeOf(BITMAPFILEHEADER));
ZeroMemory(@FileInfo, SizeOf(BITMAPINFOHEADER));

//Größe des Viewports abfragen --> Spätere Bildgrößenangaben
glGetIntegerv(GL_VIEWPORT, @Viewport);

//Initialisieren der Daten des Headers
FileHeader.bfType := 19778; //$4D42 = 'BM'
FileHeader.bfOffBits := SizeOf(BITMAPINFOHEADER)+SizeOf(BITMAPFILEHEADER);

//Schreiben der Bitmap-Informationen
FileInfo.biSize := SizeOf(BITMAPINFOHEADER);
FileInfo.biWidth := Viewport[2];
FileInfo.biHeight := Viewport[3];
FileInfo.biPlanes := 1;
FileInfo.biBitCount := 32;
FileInfo.biSizeImage := FileInfo.biWidth*FileInfo.biHeight*(FileInfo.biBitCount div 8);

//Größenangabe auch in den Header übernehmen
FileHeader.bfSize := FileHeader.bfOffBits + FileInfo.biSizeImage;

//Speicher für die Bilddaten reservieren
GetMem(pPicData, FileInfo.biSizeImage);
try
//Bilddaten von OpenGL anfordern (siehe oben)
glReadPixels(0, 0, Viewport[2], Viewport[3], GL_BGRA, GL_UNSIGNED_BYTE, pPicData);

//Und den ganzen Müll in die Datei schieben ;-)
//Moderne Leute nehmen dafür auch Streams ...
AssignFile(f, name);
Rewrite( f,1 );
try
BlockWrite(F, FileHeader, SizeOf(BITMAPFILEHEADER));
BlockWrite(F, FileInfo, SizeOf(BITMAPINFOHEADER));
BlockWrite(F, pPicData^, FileInfo.biSizeImage );
finally
CloseFile(f);
end;
finally
//Und den angeforderten Speicher wieder freigeben ...
FreeMem(pPicData, FileInfo.biSizeImage);
end;
end;</pascal>

=== Speichern im TGA Format ===

Eine TGA-Datei hat einen ähnlich einfachen Aufbau. Als erstes kommen auch hier Header-Informationen und dannach die eigentlichen Daten.

Der Header sieht diesmal so aus:
<pascal>type
TTGAHEADER = packed record
tfType : Byte;
tfColorMapType : Byte;
tfImageType : Byte;
tfColorMapSpec : Array[0..4] of Byte;
tfOrigX : Word; //Array [0..1] of Byte;
tfOrigY : Word;
tfWidth : Word;
tfHeight : Word;
tfBpp : Byte;
tfImageDes : Byte;
end;
</pascal>
Nun zur Speicherfunktion für ein Screenshot ohne Alpha Wert
<pascal>
procedure ScreenShot(const Name : string);
var
DataBuffer : array of Byte;
f : file;
tgaHeader : TTGAHEADER;
width, height : integer;
DataSize:Integer;
viewport : Array[0..3] of integer;
begin
//Viewport-Größe lesen
glGetIntegerv(GL_VIEWPORT, @viewport);
width := viewport[2];
height := viewport[3];

//Größe der Daten berechnen
DataSize := Width * Height * 3;

//Größe des Puffers festlegen (Speicher reservieren)
SetLength(DataBuffer,DataSize);

// TGA Kopf mit Daten füllen
ZeroMemory(@tgaHeader, SizeOf(tgaHeader));
tgaHeader.tfImageType := 2; // TGA_RGB = 2
tgaHeader.tfWidth := Width;
tgaHeader.tfHeight := Height;
tgaHeader.tfBpp := 24;

//Daten von OpenGL anfordern
glReadPixels(0,0,Width, Height, GL_BGR, GL_UNSIGNED_BYTE, @DataBuffer[0]);

//Datei erstellen
AssignFile(f, Name);
Rewrite( f,1 );
try
// TGA Kopf in die Datei reinschreiben
BlockWrite(F, tgaHeader, SizeOf(tgaHeader));

// Die eigentlichen Bilddaten in die Datei schreiben
BlockWrite(f, DataBuffer[0], DataSize );
finally
CloseFile(f);
end;
end;
</pascal>

=== Speichern im TGA-Format bei Nutzung von SDL ===

Das Speichern eines Screenshots im TGA-Format sieht auch bei Nutzung von SDL nicht wesentlich anders aus. Als erstes müssen die Units sdl und sdl_utils eingebunden sein, was aber sicherlich schon der Fall ist. Ansonsten einfach kurz

<pascal>uses
sdl, sdl_utils;</pascal>

und wir hätten auch dies erledigt.

Was sich allerdings etwas unterscheided, ist, dass man gegebenenfalls einige Vorkehrungen treffen muss, um die richtige Reihenfolge der einzelnen Farbkanäle zu gewährleisten, was mit folgender Routine ein leichtes ist:

<pascal>procedure SwapBGR(Surface: PSDL_Surface);
var
x,y: Integer;
pixel: UInt32;
pred, pgreen, pblue, palpha: PUInt8;
red, green, blue, alpha: UInt8;
begin
for y:=0 to (Surface.h-1) do
for x:=0 to (Surface.w-1) do
begin
//reads the pixels them
pixel:=SDL_GetPixel(Surface, x, y);

pred:=@red;
pgreen:=@green;
pblue:=@blue;
palpha:=@alpha;

//read and swap color
SDL_GetRGBA(pixel,Surface.format, pred, pgreen, pblue, palpha);
pixel:=SDL_MapRGBA(Surface.format, blue, green, red, alpha);

SDL_PutPixel(Surface, x, y, pixel);
end;
end;</pascal>

Auch hier benötigen wir wieder den TGA-Header als Record:

<pascal>type
TTGAHEADER = packed record
tfType : Byte;
tfColorMapType : Byte;
tfImageType : Byte;
tfColorMapSpec : Array[0..4] of Byte;
tfOrigX : Word;
tfOrigY : Word;
tfWidth : Word;
tfHeight : Word;
tfBpp : Byte;
tfImageDes : Byte;
end;
</pascal>

Nach diesen kleinen Vorbereitungen folgt eigentlich auch, wie gewohnt, der normale Code zum Speichern, nur eben mit SDL:

<pascal>//Speichert eine Surface in eine TGA-Datei.
//Surface wird am Ende freigegeben. Die Videosurface sollte also vorher geblittet werden
//und diese dann weitergereicht werden.
function SaveSurfacetoTGA(filename: String; surface: PSDL_Surface): Boolean;
var
TGAHEADER : TTGAHEADER;

rwop: PSDL_RWops;
ImageSize: Integer;
i : Integer;
begin
Result:=False;

//Prüfen, ob's was zu Speichern gibt ...
if not Assigned(surface) then
begin
writeln('Keine Surface übergeben');
exit;
end;

//Haben wir ein Pixelformat mit mindestens 24 Bit?
if surface.format.BytesPerPixel<3 then
begin
writeln('Farbtiefe nicht unterstützt');
exit;
end;

//Müssen wir die Reihenfolge der Farbkanäle anpassen?
if SDL_BYTEORDER<>SDL_BIG_ENDIAN then
begin
SwapBGR(surface);
end;

//Na gut, füllen wir den Header aus ...
with TGAHEADER do
begin
tfType:=0;
tfColorMapType:=0;
tfImageType:=2;
for i:=0 to 4 do
tfColorMapSpec[i]:=0;
tfOrigX:=0;
tfOrigY:=0;
tfWidth:=surface.w;
tfHeight:=surface.h;
tfBpp:=surface.format.BitsPerPixel;
tfImageDes:=0;
end;

//Ermitteln des benötigten Speicherplatze...
ImageSize:=surface.w*surface.h*surface.format.BytesPerPixel;

//Datei zum Schreiben öffnen.
rwop:=SDL_RWfromFile(PChar(filename),'w+b');
if rwop=nil then
begin
Writeln('Fehler beim Erstellen des Rwops');
exit;
end;
try
//Versuchen, den Header in die Datei zu schreiben
if SDL_RWWrite(rwop,@TGAHEADER,SizeOf(TGAHEADER),1)<>1 then
begin
writeln('Fehler beim Schreiben des Headers');
exit;
end;

//Versuchen, die Bilddaten in die Datei zu schreibenSchreiben der Bilddaten
if SDL_RWWrite(rwop,surface.pixels,ImageSize,1)<>1 then
begin
writeln('Fehler beim Schreiben der Daten');
exit;
end;

//Scheinbar waren wir erfolgreich
Result:=True;
finally
//Datei schließen ...
SDL_RWClose(rwop);

//Und das Surface freigeben
SDL_FreeSurface(surface);
end;
end;</pascal>

That's it. Have a nice day!

== Siehe Auch ==
[[Tutorial Renderpass]] (Dieses Tutorial erklärt wie man das gerenderte zu anderen Zwecken verwenden kann.)

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

Tutorials

2008-10-14T18:18:47Z

Yogu: Weiterleitung erstellt

#REDIRECT [[Tutorial]]

Text ausgeben

2008-10-13T17:43:48Z

Yogu: Überschriftenverschachtelung beginnt bei Ebene 2 (an Wikipedia-Standard angelehnt)

Allen Möglichkeiten gemein ist das die Buchstaben in [[Liste]]n gespeichert werden um so per [[glCallLists]] den Text ausgeben zu können.

== Buchstaben aus Pixeln ==

Die primitivste Art Buchtaben auszugeben besteht darin einfach [[glBitmap]] aufzurufen.

Falls das Betriebssystem Windows ist, kann mit [[wglUseFontBitmaps]] aus einer Windows Schrift [[glBitmap]] Befehle generiert, und in einer [[Liste]] abgespeichert werden.

=== Position festlegen ===
Die Position der Ausgabe erfolgt durch [[glRasterPos]], oder besser falls verfügbar durch [[glWindowPos]].

=== Farbe ===
Die [[Farbe]] der Schrift wird zum Zeitpunkt des letzen [[glRasterPos]] Aufrufes festgelegt. Auch wenn danach die atkive Farbe mit [[glColor]] abgeändert wird, ändert sich hierdurch nichts an der Farbe mit der die Buchstaben ausgegeben werden. (siehe [[glRasterPos]])

== 3D Schriften mit Windows ==

Per [[wglUseFontOutlines]] wird aus einer Windows Schrift für jeden Buchstaben eine Liste erstellt, welche die entsprechenden Polygone enthält.

{|
|+Das kann dann so aussehen:
|[[Bild:WglUseFontOutlines Beispiel.png]]
|}
 

== Schrift aus Texturen ==
(Sogenannte Texturefonts)

Benötigt wird für diese Technik eine Textur, auf dem alle 256 Zeichen untergebracht sind. Die Anordnung der Zeichen ist prinzipiell beliebig, nur sollte man dies so tun, dass man nachher leicht die Position der einzelnen Zeichen auf der Textur herausfindet. (z.B. indem man die Zeichen als 16x16 Zeichen Matrix anordnet).

Zusätzliche Informationen über die Breite der Buchstaben, ermöglicht es gleich große Zwischenräume zwischen den einzenen Buchstaben zu haben.
Entsprechende [[Tool]]s erleichtern die Erstellung solcher Texturen.

Die Textur [[Matrix]] wird dann mit [[glScale]] und [[glTranslate]] so manipuliert, dass das mit [[glBegin]], [[glTexCoord]] und [[glVertex]] gezeichnete Rechteck immer nur ein Zeichen enthält.
('''glScale''' ist eigentlich nicht nötig, da ein mit [[glTexCoord]] abgesteckter Texturabschnitt automatisch auf die Größe des unterligenden Polygons (gezeichnet mit [[glBegin]]-[[glEnd]] und [[glVertex]]) gedehnt wird.)

Um nur die Buchstaben ohne den Hintergrund (der Textur) zu sehen sollte dieser mittels [[Blenden|Blending]] oder (wenn man scharfe Kanten möchte) mittels [[glAlphaFunc]] heraus gefiltert werden.

=== Position ===
Das '''Wo''' wird über die Koordinaten der [[Eckpunkt|Eckpunkte]] des unterliegenden Polygons geregelt. Welches Zeichen tatsächlich ausgegeben wird, bestimmen die Texturkoordinaten (übergeben mit [[glTexCoord]]).

=== Farbe ===
Wenn man eine einfarbige Schrift möchte, so empfiehlt es sich die Textur komplett Weiß zu machen, damit man mit [[glColor]] die Textur einfärben kann und damit alle Farben anzeigen lassen kann. Dies kann beispielsweise auch mittels
[[glPixelTransfer]]f( GL_RED_BIAS, 1.0 );
[[glPixelTransfer]]f( GL_GREEN_BIAS, 1.0 );
[[glPixelTransfer]]f( GL_BLUE_BIAS, 1.0 );
vor dem Erstellen der Textur erfolgen.
Der eigentliche Zeichensatz sollte (sofern man einfarbige Schrift möchte) nur den Alpha-Kanal beeinflussen, was beispielsweise mittels
[[gluBuild2DMipmaps]]( GL_TEXTURE_2D, 2, Texturbreite, Texturhoehe, GL_ALPHA, GL_UNSIGNED_BYTE, Pixel );
gemacht werden kann. Zu beachten ist hier, dass 2 oder 4 Farbkomponenten benötigt werden damit die Textur Alphawerte erhält.

Falls der Text nicht im dreidimensionalen Raum angezeigt werden soll, empfiehlt es sich den [[Tiefentest]] zu deaktivieren und die Projektions Matrix mit [[gluOrtho2D]] neu einzustellen.

== Siehe auch ==
[[glBegin]], [[glColor]], [[glScale]], [[glTranslate]], [[glTexCoord]], [[glVertex]]

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

Text ausgeben

2008-10-13T17:40:52Z

Yogu: Oberste Überschrift entfernt & dreidimensional in ein Wort gepackt

Allen Möglichkeiten gemein ist das die Buchstaben in [[Liste]]n gespeichert werden um so per [[glCallLists]] den Text ausgeben zu können.

= Buchstaben aus Pixeln =

Die primitivste Art Buchtaben auszugeben besteht darin einfach [[glBitmap]] aufzurufen.

Falls das Betriebssystem Windows ist, kann mit [[wglUseFontBitmaps]] aus einer Windows Schrift [[glBitmap]] Befehle generiert, und in einer [[Liste]] abgespeichert werden.

== Position festlegen ==
Die Position der Ausgabe erfolgt durch [[glRasterPos]], oder besser falls verfügbar durch [[glWindowPos]].

== Farbe ==
Die [[Farbe]] der Schrift wird zum Zeitpunkt des letzen [[glRasterPos]] Aufrufes festgelegt. Auch wenn danach die atkive Farbe mit [[glColor]] abgeändert wird, ändert sich hierdurch nichts an der Farbe mit der die Buchstaben ausgegeben werden. (siehe [[glRasterPos]])

= 3D Schriften mit Windows

Per [[wglUseFontOutlines]] wird aus einer Windows Schrift für jeden Buchstaben eine Liste erstellt, welche die entsprechenden Polygone enthält.

{|
|+Das kann dann so aussehen:
|[[Bild:WglUseFontOutlines Beispiel.png]]
|}
 

= Schrift aus Texturen =
(Sogenannte Texturefonts)

Benötigt wird für diese Technik eine Textur, auf dem alle 256 Zeichen untergebracht sind. Die Anordnung der Zeichen ist prinzipiell beliebig, nur sollte man dies so tun, dass man nachher leicht die Position der einzelnen Zeichen auf der Textur herausfindet. (z.B. indem man die Zeichen als 16x16 Zeichen Matrix anordnet).

Zusätzliche Informationen über die Breite der Buchstaben, ermöglicht es gleich große Zwischenräume zwischen den einzenen Buchstaben zu haben.
Entsprechende [[Tool]]s erleichtern die Erstellung solcher Texturen.

Die Textur [[Matrix]] wird dann mit [[glScale]] und [[glTranslate]] so manipuliert, dass das mit [[glBegin]], [[glTexCoord]] und [[glVertex]] gezeichnete Rechteck immer nur ein Zeichen enthält.
('''glScale''' ist eigentlich nicht nötig, da ein mit [[glTexCoord]] abgesteckter Texturabschnitt automatisch auf die Größe des unterligenden Polygons (gezeichnet mit [[glBegin]]-[[glEnd]] und [[glVertex]]) gedehnt wird.)

Um nur die Buchstaben ohne den Hintergrund (der Textur) zu sehen sollte dieser mittels [[Blenden|Blending]] oder (wenn man scharfe Kanten möchte) mittels [[glAlphaFunc]] heraus gefiltert werden.

== Position ==
Das '''Wo''' wird über die Koordinaten der [[Eckpunkt|Eckpunkte]] des unterliegenden Polygons geregelt. Welches Zeichen tatsächlich ausgegeben wird, bestimmen die Texturkoordinaten (übergeben mit [[glTexCoord]]).

== Farbe ==
Wenn man eine einfarbige Schrift möchte, so empfiehlt es sich die Textur komplett Weiß zu machen, damit man mit [[glColor]] die Textur einfärben kann und damit alle Farben anzeigen lassen kann. Dies kann beispielsweise auch mittels
[[glPixelTransfer]]f( GL_RED_BIAS, 1.0 );
[[glPixelTransfer]]f( GL_GREEN_BIAS, 1.0 );
[[glPixelTransfer]]f( GL_BLUE_BIAS, 1.0 );
vor dem Erstellen der Textur erfolgen.
Der eigentliche Zeichensatz sollte (sofern man einfarbige Schrift möchte) nur den Alpha-Kanal beeinflussen, was beispielsweise mittels
[[gluBuild2DMipmaps]]( GL_TEXTURE_2D, 2, Texturbreite, Texturhoehe, GL_ALPHA, GL_UNSIGNED_BYTE, Pixel );
gemacht werden kann. Zu beachten ist hier, dass 2 oder 4 Farbkomponenten benötigt werden damit die Textur Alphawerte erhält.

Falls der Text nicht im dreidimensionalen Raum angezeigt werden soll, empfiehlt es sich den [[Tiefentest]] zu deaktivieren und die Projektions Matrix mit [[gluOrtho2D]] neu einzustellen.

=Siehe auch=
[[glBegin]], [[glColor]], [[glScale]], [[glTranslate]], [[glTexCoord]], [[glVertex]]

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

glBitmap

2008-08-29T10:27:48Z

Yogu: /* Beispiel */ Formatierung des ersten "nil"

= glBitmap =

{{Hinweis|Den Texturloader "glBitmap" von Lossy eX findet man unter [[Glbitmap_loader]]}}

== Name ==
'''glBitmap''' - Zeichnet ein Bitmap.

== Delphi-Spezifikation ==
procedure '''glBitmap'''(''width,height'': TGLsizei; ''xorig, yorig'': TGLfloat;
''xmove,ymove'': TGLfloat; '''const''' ''bitmap'': PGLubyte);

 
== Parameter ==

{| border="1" rules="all"
| ''width,height''
| Bestimmen die Größe der Bitmap.
|-
| ''xorig, yorig''
| Bestimmt den Koordinaten Ursprung(von links,unten) innerhalb des Bitmaps.
|-
| ''xmove, ymove''
| Legt fest um wieviel die aktuelle Rasterposition verschoben werden soll.
|-
| ''bitmap''
| Ein Zeiger auf die Bitmap('''Achtung''': Entspricht nicht dem TBitmap aus Delphi)
|}

== Beschreibung ==
An der aktuellen Rasterposition wird überall dort wo im Bitmap eine 1 ist wird gezeichnet. Der Bereich des Bitmaps der eine 0 beihnhaltet bleibt unberührt.
Anschließend wird die aktuelle Rasterposition um ''xmove'' und ''ymove'' erhöht.

== Hinweise ==
Falls die aktuelle Rasterposition ungültig ist, wird glBitmap ignoriert.

Die Fenster-Koordianten an denen das Bitmap gezeichnet wird errechnet man durch:

Fenster.X := Rasterposition.X - Bitmap_Ursprung.X ;
Fenster.Y := Rasterposition.Y - Bitmap_Ursprung.Y ;

[[Bild:GlBitmap.png|right]]
Möchte man etwa den Buchstaben klein "g" etwas tiefer positionieren so kann man sich diese Eigenschaft von glBitmap zu Nutze machen und den Urspung etwas höher ansetzen.

Beim Zeichnen wird die aktuellen Rasterfarbe (bzw. dem aktuellen Raster Index)
verwendet sowie die aktuellen Raster Textur Koordianten.
Die Z Position wird von der aktullen Rasterposition bezogen.

Die erzeugten Pixel-Fragmente werden so behandelt als wären sie von Polygon, Linen und Punkten unter der Benutzung von [[Nebel]], [[texture mapping]] und anderen Pixel Operatoren (wie etwa Alpha- und Tiefen Test) erstellt worden.

Die Bitmaps brauchen zur Speicherung einer Bit-Zeile immer 32 Bit egal wieviel Spalten davon genutzt werden.

== Fehlermeldungen ==
GL_INVALID_VALUE wird generiert wenn der Parameter width oder height negativ ist.
GL_INVALID_OPERATION wird generiert wenn glBitmap zwischen [[glBegin]] und dem dazugehörigen [[glEnd]] aufgerufen wird.

== Zugehörige Wertrückgaben ==
*[[glGet]] mit Token [[glGet#GL_CURRENT_RASTER_POSITION|GL_CURRENT_RASTER_POSITION]]
*[[glGet]] mit Token [[glGet#GL_CURRENT_RASTER_COLOR|GL_CURRENT_RASTER_COLOR]]
*[[glGet]] mit Token [[glGet#GL_CURRENT_RASTER_INDEX|GL_CURRENT_RASTER_INDEX]]
*[[glGet]] mit Token [[glGet#GL_CURRENT_RASTER_TEXTURE_COORDS|GL_CURRENT_RASTER_TEXTURE_COORDS]]
*[[glGet]] mit Token [[glGet#GL_CURRENT_RASTER_POSITION_VALID|GL_CURRENT_RASTER_POSITION_VALID]]

==Beispiel==

'''type'''
TBitmap='''array''' [0..7,0..3] '''of''' Byte;
'''var'''
Bitmap:TBitmap;

'''procedure''' OnCreate;''//Wird beim Start aufgerufen''
'''type'''
Bit=0..1;
'''function''' BinByte(B128,B64,B32,B16,B8,B4,B2,B1:Bit):Byte;
'''begin'''
result := 0;
'''if '''B128 <> 0 '''then '''Inc(result,128);
'''if '''B64 <> 0 '''then '''Inc(result,64);
'''if '''B32 <> 0 '''then '''Inc(result,32);
'''if '''B16 <> 0 '''then '''Inc(result,16);
'''if '''B8 <> 0 '''then '''Inc(result,8);
'''if '''B4 <> 0 '''then '''Inc(result,4);
'''if '''B2 <> 0 '''then '''Inc(result,2);
'''if '''B1 <> 0 '''then '''Inc(result,1);
'''end''';
'''begin'''
Bitmap[7][0] := BinByte(1,1,1,1,1,1,1,0);
Bitmap[6][0] := BinByte(0,1,1,1,1,1,1,0);
Bitmap[5][0] := BinByte(0,1,1,0,0,0,1,0);
Bitmap[4][0] := BinByte(0,1,1,1,1,0,0,0);
Bitmap[3][0] := BinByte(0,1,1,1,1,0,0,0);
Bitmap[2][0] := BinByte(0,1,1,0,0,0,0,0);
Bitmap[1][0] := BinByte(0,1,1,0,0,0,0,0);
Bitmap[0][0] := BinByte(1,1,1,1,0,0,0,0);

Bitmap[7][1] := BinByte(1,1,1,1,0,0,0,0);
Bitmap[6][1] := BinByte(0,1,1,0,0,0,0,0);
Bitmap[5][1] := BinByte(0,1,1,0,0,0,0,0);
Bitmap[4][1] := BinByte(0,1,1,0,0,0,0,0);
Bitmap[3][1] := BinByte(0,1,1,0,0,0,0,0);
Bitmap[2][1] := BinByte(0,1,1,0,0,0,1,0);
Bitmap[1][1] := BinByte(0,1,1,1,1,1,1,0);
Bitmap[0][1] := BinByte(1,1,1,1,1,1,1,0);

Bitmap[7][2] := BinByte(0,0,1,1,1,1,0,0);
Bitmap[6][2] := BinByte(0,1,1,1,1,1,1,0);
Bitmap[5][2] := BinByte(1,1,0,0,0,0,1,1);
Bitmap[4][2] := BinByte(1,1,0,0,0,0,1,1);
Bitmap[3][2] := BinByte(1,1,0,0,0,0,1,1);
Bitmap[2][2] := BinByte(1,1,0,0,0,0,1,1);
Bitmap[1][2] := BinByte(0,1,1,1,1,1,1,0);
Bitmap[0][2] := BinByte(0,0,1,1,1,1,0,0);

Bitmap[7][3] := BinByte(0,0,0,0,0,0,0,0);
Bitmap[6][3] := BinByte(0,0,0,0,0,0,0,0);
Bitmap[5][3] := BinByte(0,0,0,0,0,0,0,0);
Bitmap[4][3] := BinByte(1,1,1,1,1,1,1,1);
Bitmap[3][3] := BinByte(1,1,1,1,1,1,1,1);
Bitmap[2][3] := BinByte(0,0,0,0,0,0,0,0);
Bitmap[1][3] := BinByte(0,0,0,0,0,0,0,0);
Bitmap[0][3] := BinByte(0,0,0,0,0,0,0,0);
'''end''';

'''procedure''' Draw;''//Zeichen Routine''
'''begin'''
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
glBitmap(0,0,0,0,300,200,'''nil''');
glBitmap(8,8,0,6, 0,0,@Bitmap[0,3]);''//Gibt Bit-Spalten 25-32 aus(_)''
glBitmap(8,8,0,0,10,0,@Bitmap[0,0]);''//Gibt Bit-Spalten 1-8 aus(F)''
glBitmap(8,8,0,0,10,0,@Bitmap[0,1]);''//Gibt Bit-Spalten 9-16 aus(L)''
glBitmap(8,8,0,0,10,0,@Bitmap[0,2]);''//Gibt Bit-Spalten 17-24 aus(O)''
glBitmap(8,8,0,0,10,0,@Bitmap[0,3]);''//Gibt Bit-Spalten 25-32 aus(-)''
glBitmap(20,8,0,0,0,0,@Bitmap[0,0]);''// Gibt Bit-Spalten 1-20 aus(FL()''
glBitmap(0,0,0,0,-40,0,'''nil'''); ''//Zurück''
glBitmap(0,0,0,0,-300,-200,'''nil'''); ''//Zurück''
'''end''';

== Siehe auch ==
[[wglUseFontBitmaps]], [[glBegin]], [[glDrawPixels]], [[glRasterPos]], [[glPixelStore]], [[glPixelTransfer]]

Texturloader "[[Glbitmap loader|glBitmap.pas]]"

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

glTexImage

2008-07-13T18:45:44Z

Yogu: /* Parameter */ Beschreibung von 'pixels'

= glTexImage =

== Name ==
'''glTexImage''' - Einstellungen zum Texturen zeichnen

== Spezifikation ==
procedure '''glTexImage1D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage2D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''border'': TGLint; ''format'': TGLenum; ''_type'': TGLenum;
'''const''' ''pixels'': PGLvoid); 
procedure '''glTexImage3D'''(''target'': TGLenum; ''level'': TGLint; ''internalformat'': TGLint; ''width'': TGLsizei;
''height'': TGLsizei; ''depth'': TGLsizei; ''border'': TGLint; ''format'': TGLenum;
''_type'': TGLenum; '''const''' ''pixels'': PGLvoid); 

== Parameter ==
<table border=1 rules=all>
<tr>
<td>''target''</td>
<td>Gibt an, welche Texture erreicht werden soll. Muss je nach Funktionsaufruf '''GL_TEXTURE_1D,GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' sein.</td>
</tr>
<tr>
<td>''level''</td>
<td>Gibt den Detailgrad für das gewünschte Bild an. 
''level'' '''0''' ist das Basisbild. Level n ist die n-te Mipmap reduzierung des Bildes.</td>
</tr>
<tr>
<td>''internalformat''</td>
<td>'''1''' für '''R''' '''2''' für '''R''' und '''A''' '''3''' für '''RGB''' '''4''' für '''RGBA'''</td>
</tr>
<tr>
<td>''width'',</td>
<td>Breite = Anzahl der Pixel pro Zeile muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben.</td>
</tr>
<tr>
<td>''height'',</td>
<td>Höhe = Anzahl der Zeilen muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''depth'',</td>
<td>Tiefe = Anzahl der "Scheiben" muss als Wert 2^n (+ 2 * (border) ) für n Integerwerte haben</td>
</tr>
<tr>
<td>''border'',</td>
<td>Breite des Rahmens || '''0''' oder '''1'''</td>
</tr>
<tr>
<td>''format''</td>
<td>Bestimmt das Format der Pixeldaten. Folgende symbolische Werte werden akzeptiert: 
'''GL_COLOR_INDEX, GL_RED, GL_GREEN, GL_BLUE, GL_ALPHA, GL_RGB, GL_RGBA, GL_LUMINANCE,''' und '''GL_LUMINANCE_ALPHA'''</td>
</tr>
<tr>
<td>''_type''</td>
<td>Bestimmt den Pixeltyp für den Inhalt von ''pixels''. Folgende Typen werden unterstützt: 
'''GL_UNSIGNED_BYTE, GL_BYTE, GL_UNSIGNED_SHORT, GL_SHORT, GL_UNSIGNED_INT, GL_INT, GL_FLOAT, GL_BITMAP'''</td>
</tr>
<tr>
<td>''pixels''</td>
<td>Die Texture-Image Daten vom Typ, der in ''format'' angegeben wurde (Array, in dem die Pixel gespeichert sind) </td>
</tr>
</table>

== Beschreibung ==
Texturierung bildet einen bestimmten Teil eines Texturbildes auf alle [[Primitive|Grafikprimitiven]] ab für die Texturierung aktiviert ist.

Je nachdem welche Texturart aktiviert werden soll ruft man [[glEnable]] mit den Parametern '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' auf. Die Deaktivierung erfolgt entsprechend mittels [[glDisable]].

Die Texturbilder werden durch die Funktionen '''glTexImage1D, glTexImage2D''' bzw. '''glTexImage3D''' definiert. Die Argumente der Funktionen beschreiben die Eigenschaften des Texturbildes wie z.B. Breite, Höhe, Tiefe (je nach Dimension), Breite des Randes, [[LOD]]-Nummer (siehe [[glTexParameter]]) und Anzahl der unterstützen Farbkomponenten. Die letzten 3 Argumente beschreiben wie das Bild im Speicher abgelegt wird. Die 3 Argumente sind identisch mit denen, die das Pixelformat bei [[glDrawPixels]] steuern.

Die Daten werden aus ''pixels'' als Sequenz von vorzeichenlosen oder -behafteten Byte-, Shortint- oder Longint-Werten oder als Fließkommazahlen einfacher Genauigkeit gelesen. Der Typ wird über ''type'' festgelegt. 
Die ausgelesen Werte werden abhängig von ''format'' gruppiert zu Gruppen mit je einem, zwei, drei oder vier Werten. Diese Gruppen entsprechen einem Element.

Wenn ''type'' gleich '''GL_BITMAP''' ist, werden die Daten als Folge (orig.: "String") von vorzeichenlosen Bytewerten angesehen (wobei ''format'' '''GL_COLOR_INDEX''' sein muss). Jedes Byte des Datenblocks wird als Gruppe von 8 1-Bit Elementen interpretiert. Die Reihenfolge der Bits wird durch '''GL_UNPACK_LSB_FIRST''' (siehe [[glPixelStore]]) festgelegt.

Der ''format'' Parameter bestimmt die Zusammenstellung der Elemente aus ''pixels''. Folgende 9 möglichen Werte kann ''format'' haben:

'''GL_COLOR_INDEX'''
:Jedes Element entspricht einem einzelnen Wert, dem Farbindex. Jeder Index wird in eine Festkommazahl (mit einer unbestimmten Anzahl 0 Bits rechts vom Komma) konvertiert, abhängig von Wert und Vorzeichen von '''GL_INDEX_SHIFT''' bitweise nach rechts bzw. links verschoben und zu GL_INDEX_OFFSET addiert. Dann werden die Indizes durch ihre entsprechenden Werte aus den Tabellen '''GL_PIXEL_MAP_I_TO_R''', '''GL_PIXEL_MAP_I_TO_G''', '''GL_PIXEL_MAP_I_TO_B''' und '''GL_PIXEL_MAP_I_TO_A''' ersetzt und auf das Interval [0, 1] heruntergerechnet.

'''GL_RED'''
:Jedes Element entspricht einer roten Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_GREEN'''
:Jedes Element entspricht einer grünen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_BLUE'''
:Jedes Element entspricht einer blauen Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die beiden anderen Farben und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_ALPHA'''
:Jedes Element entspricht einer Alpha-Farbkomponente. Der Wert wird in eine Fließkommazahl konvertiert und zu einem RGBA Wert ergänzt, indem man 0.0 für die drei anderen Farben hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGB'''
:Jedes Element entspricht den drei RGB-Farbwerten. Die Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_RGBA'''
:Jedes Element enthält alle vier Farbkomponenten. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE'''
:Jedes Element entspricht einem Helligkeitswert. Der Wert wird in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und 1.0 für den Alphakanal hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

'''GL_LUMINANCE_ALPHA'''
:Jedes Element entspricht einem Paar aus Helligkeitswert und Alphawert. Beide Werte werden in Fließkommazahlen konvertiert und zu einem RGBA Wert ergänzt, indem man den Helligkeitswert drei mal für R, G und B einsetzt und den Alphawert hinzufügt. Jede Komponente wird mit '''GL_'''''c'''''_SCALE''' multipliziert und zu '''GL_'''''c'''''_BIAS''' addiert, und am Schluss auf den Bereich [0,1] begrenzt, wobei ''c'' durch R, G, B oder A ersetzt werden soll. (siehe [[glPixelTransfer]])

Lesen Sie den Artikel [[glDrawPixels]] um eine Beschreibung der zulässigen Werte für ''type'' zu erhalten.

Ein Texturbild kann bis zu 4 Farbkomponenten pro Texturelement ([[Texel]]) besitzen. Dies wird über den Parameter ''internalformat'' geregelt. 
Ein Texturbild welches nur eine Komponente besitzt, beenutzt nur die Rotwerte der aus ''pixels'' extrahierten RGBA Farbe. 
Ein Texturbild mit zwei Komponenten benutzt nur die Rot und Alpha Komponenten. 
Ein Texturbild mit drei Komponenten benutzt nur die Rot, Grün und Blau Komponenten. 
Ein Texturbild mit vier Komponenten benutzt alle RGBA Farbkomponenten. 

===Verwendungsmöglichkeit===
Abseits dem einfachen Laden von Texturen wird diese Funktion auch benutzt um Speicherbereiche für die spätere Verwendung zu reservieren. Ruft man glTexImage mit ''pixels'' = '''nil''' auf, wird der Speicherbereich zwar angelegt aber nicht gefüllt. Dies kann zum Beispiel gewünscht sein, wenn man einen Screenshot als Textur verwenden möchte ("Render To Texture"). Man kann dann den [[Framebuffer]] (=Screenshot) mittels [[glCopyTexImage]] in den durch glTexImage reservierten Speicherbereich kopieren. (Siehe dazu auch diesen [http://www.delphigl.com/forum/viewtopic.php?p=59156 Thread im Forum])

== Hinweise ==
'''glTexImage3D''' war bis zu OpenGL 1.2 nur eine Erweiterung. Deswegen ist bei manchen Chipsätzen die Funktion nur als '''glTexImage3DEXT''' verfügbar.

Texturierung hat im Farbindexmodus keinen Effekt.

Das Texturbild kann in den selben Datenformaten vorliegen wie die Pixel bei [[glDrawPixels]] ausgenommen '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT'''. [[glPixelStore]] und [[glPixelTransfer]] beeinflussen das Texturebild in exakt der Art und Weise, wie sie auch [[glDrawPixels]] beeinflussen.

Eine Textur die 0 Pixel hoch oder breit ist, stellt die NULL-Textur dar. Wenn die NULL-Textur für die LOD-Stufe 0 spezifiziert wird entspricht das Verhalten dem bei deaktivierter Texturierung.

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:

=== Ab OpenGL Version 1.3 ===
[[GL_ARB_texture_cube_map]] definiert weitere 6 2D-Texture-Typen welche als ''target'' angegeben werden können.

== Fehlermeldungen ==

'''GL_INVALID_ENUM''' wird generiert wenn ''target'' nicht '''GL_TEXTURE_1D, GL_TEXTURE_2D''' oder '''GL_TEXTURE_3D''' ist. (entsprechend der benutzten Funktion) 

'''GL_INVALID_ENUM''' wird generiert wenn ''format'' ungültige Werte übergeben wurden. Akzeptiert werden alle Formatangaben außer '''GL_STENCIL_INDEX''' und '''GL_DEPTH_COMPONENT''' 

'''GL_INVALID_ENUM''' wird generiert wenn ''type'' keine gültige Typkonstante übergeben wurde. 

'''GL_INVALID_ENUM''' wird generiert wenn GL_BITMAP als ''type'' und '''GL_COLOR_INDEX nicht(!)''' als ''format'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''level'' kleiner 0 oder größer ld(max) ist, wobei max der Rückgabewert von '''GL_MAX_TEXTURE_SIZE''' ist. (ld = Logarithmus Dualis = Basis 2). 

'''GL_INVALID_VALUE''' wird generiert wenn für ''internalformat'' etwas anderes als ''1'', ''2'', ''3'' oder ''4'' angegeben wurde. 

'''GL_INVALID_VALUE''' wird generiert wenn ''width'', ''height'' bzw. ''depth'' (je nach Funktion) kleiner als 0 oder größer als 2 + '''GL_MAX_TEXTURE_SIZE''' ist, oder die Bedingung 2^k + 2 * (border) (k=Integerwerte) nich erfüllt. 

'''GL_INVALID_VALUE''' wenn ''border'' nicht ''0'' oder ''1'' ist. 

'''GL_INVALID_OPERATION''' wird generiert wenn eine '''glTexImage'''-Funktion in einem [[glBegin]]- und [[glEnd]]-Block aufgerufen wird. 

== Zugehörige Wertrückgaben ==
[[glGetTexImage]] 
[[glIsEnabled]] mit dem Token '''GL_TEXTURE_1D''', '''GL_TEXTURE_2D''' bzw. '''GL_TEXTURE_2D'''.

== Siehe auch ==
[[glTexEnv]], [[glTexGen]], [[glTexSubImage1D]], [[glTexSubImage2D]], [[glTexSubImage3D]], [[glTexParameter]], [[glTexCoord]]

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

SDL GetError

2008-07-12T12:03:31Z

Yogu: /* Siehe auch */ Groß-/Kleinschreibung

= SDL_GetError =

== Name ==
'''SDL_GetError''' - Liefert einen String zurück der den letzten aufgetretenen Fehler näher beschreibt.

== Delphi-Spezifikation ==
function '''SDL_GetError''': PChar;

== Beschreibung ==
'''SDL_GetError''' liefert einen String zurück der den letzten aufgetretenen Fehler näher beschreibt. Besonders bei der Initalisierung sollte überprüft werden, ob angeforderte Ressourcen auch zur Verfügung stehen. Wird statt eines Ergebnisses ein NIL-Wert zurückgegeben, empfiehlt es sich mit '''SDL_GetError''' den aufgetretenen Fehler auszugeben. Dies erleichtert in der Praxis sehr häufig die Diagnose eines Problems.

== Beispiel ==
Wir versuchen künstlich einen Fehler hervorzurufen indem wir als gewünschte Bildschirmauflösung negative Werte angeben. Die daraus resultierende Ausgabe lautet: ''Invalid width or height''
<pascal>[...]
surface := SDL_SetVideoMode(-800, -600, -32, videoflags);
if not assigned(surface) then
begin
WriteLn(SDL_GetError);
Quit_App;
end;
[...]</pascal>

== Siehe auch ==
[[glGetError]]

[[Kategorie:SDL|GetError]]

Blackbox

2008-07-08T14:14:00Z

Yogu: Komma eingefügt

==BlackBox==
Eine BlackBox beschreibt im Technischen Gebiet eine Schaltung, von der nur ihre Wirkung bekannt ist und daraus Schlussfolgerungen auf den Inhalt gemacht werden.

Blackboxes werden benutzt um Informationsmengen einzuschränken. Denn häufig ist es nur wichtig zu wissen, '''was''' ein Programmteil macht, aber nicht '''wie'''. Deshalb werden die betreffenden Teile durch eine Blackbox ersetzt. Von einer Blackbox ist nur bekannt was sie als Eingaben benötigt und was sie bewirkt bzw. welche Ausgaben sie erzeugt.

==Reverse Engineering==
Will man den Inhalt einer Blackbox rekonstuieren kann man den Ansatz des Reverse Engenierings versuchen.

Ein Beispiel wäre folgendes:

function extractfilename(file:string):string;
begin
//Unbekannt
result:=rueckgabewert;
end;

Nun fangen wir an alles von hinten aufzurollen und eventuell ein grossteil des Codes zu bekommen.

function extractfilename(file:string):string;
var //Variable zum zwischenspeichern und bearbeiten des strings
filename:string;
begin
filename:=file;
//Unbekannt
result:=filename;
end;

Wir wissen nun, dass der fehlende Code den Dateinamen aus dem String kopiert.
Des weiterem ist uns bekannt das ein Dateiname am Ende einer Pfadhierachy steht und die Pfade durch ein '/' oder '\' Zeichen getrennt werden. Das bedeutet wir suchen das letze '/' oder '\' Zeichen im String und kopieren alles von der Position bis Stringende.

function extractfilename(file:string):string;
var
filename:string;
ind:integer;
begin
filename:=file;
for ind:=high(filename) downto 0 do
if (filename[ind]='/') or (filename[ind]='\') then break;
copy(filenam,ind,length(file)-ind);
result:=filename;
end;

Enginepfad

2008-07-08T14:11:03Z

Yogu: /* Vorbereitung */ Was zum Teufel ist AI? (-> Künstliche Intelligenz)

=Der Enginepfad=

==Einführung==
Willkommen auf dem '''Enginepfad''' des DelphiGL-Wikis. Dieser Pfad soll euch zeigen wie man eine Engine von Grund auf konzipieren und realisieren kann.

Wie funktioniert der Trampelpfad? Im nachfolgenden Abschnitt findet ihr einen Text, der euch etwas über Engines erzählen soll. Dieser Text ist durchsetzt mit Schlagwörtern, welche Links auf andere Artikel im Wiki sind. Wenn ihr diesen Links folgt, erfahrt ihr mehr zu den entsprechenden Themen.

Sinn des Trampelpfades ist es, euch die Artikel aufzuzeigen, welche ihr gelesen haben solltet und welche nützlich für den Einstieg in OpenGL sind. Am Ende dieses Trampelpfades findet ihr noch Links, die euch die Materie genauer erklären werden.

==Der Trampelpfad==
Am Beginn steht bei den meisten Anfängern zum Thema [[Engine]] die Frage "Was brauch' ich um eine Engine zu entwickeln?". Je nach dem welches Betriebsystem ihr als Plattform gewählt habt, können sich die Hilfsmittel unterscheiden.

Weiterhin ist die Wahl der Sprache zu treffen.
Wenn ihr mit Object Pascal in seinen vielen Varianten (z.B. '''Delphi''') arbeiten wollt, dann ist der [[DGLOpenGL.pas]]-Header genau das richtige für euch. Wenn es eine andere Sprache sein soll, müsst ihr euch dann nach einen aktuellen Header in Google umschauen. Es ist im vorhinein schon zu erwähnen, dass dieses Wiki Object Pascal in seiner Vielfalt verwendet.

==Vorbereitung==
Als erstes muss uns klar werden, welches Ausmaß die Engine erreichen soll. Davon abhängig ist unsere Planung zu gestalten:
:1. Es ist ratsam mit der Plattformunterstützung anzufangen, da diese unsere unterste Schicht bilden wird.
:Hier ist als erstes zu sagen, je mehr Plattformen unterstütz werden sollen, desto aufwendiger wird das Projekt.
:Mit Plattformen sind hier z.B. PC mit 32Bit/64Bit, Konsolen (PS1-3, XBox-360, Wii, GP2X, ...) und mobile Geräte (Palm, PSP,...) gemeint.
:Für jede Plattform gibt es eine oder mehrere Betriebssysteme zur Ansteuerung der Hardware.
:Hier eine kleine Liste mit verschiedenen Betriebssystemen:
:*Windows
:*Linux
:*MacOS X

:2. Abhängig davon wählen wir nun unseren Compiler.
:*[http://www.borland.de/delphi/ Delphi] (Windows 32Bit)
:*[http://www.freepascal.org/ FreePascal] (Unterstützung für alle erwähnten Plattformen und OS)
:*[http://www.gnu.org/software/gcc/gcc.html gcc] (Unterstützungen für alle erwähnten Plattformen und OS)
:*[http://www.borland.de/kylix/ Kylix] (Linux 32Bit) (Veraltet, nicht mehr in Entwicklung)
:*[http://msdn.microsoft.com/visualc/ VisualC++] (Windows 32/64Bit WinCE)

:3. Nun sollten wir entscheiden, welche Bibliothek wir für das Ansprechen der Grafikkarte verwenden:
:Es gibt einige wie z.B. DirectX, GDI, AGG und Mesa aber wir wollen uns mit [[OpenGL]] auseinander setzen, denn dieses ist ein OpenGL Wiki.
{{Hinweis|Dieser [[OpenGL Verwendungspfad|Verweis]] führt Sie auf den Verwendungspfad in diesem Wiki und soll zeigen wie man OpenGL unter den einzelnen OS nutzten kann}}

:4. Nun kommen wir zu allgemeinen Bibliotheken für das Ansteuern unserer Hardware.
:Im Voraus ist zu sagen, dass ALSA und OSS Treiber unter Linux sind, die das Abspielen von Sound ermöglichen. Nur nur ein Bruchteil der Bibliotheken ist für 3D Sound ausgelegt und man müsste bei Bedarf noch einen eigene Dopplereffekt hinzufügen.
:Sound:
:*ALSA (Linux)
:*[http://www.un4seen.com/ BASS]
:*[[Direct Sound]] (Windows)
:*[http://www.fmod.org/ FMOD]
:*[[OpenAL]]
:*OSS (Nur Linux)
:*[[SDL]]
:Netzwerk:
:*DirectX Net (Windows)
:*[[SDL_Net]]
:*Raknet

:5. Jetzt sollte man entscheiden, ob und welche Bibliotheken man zur Erleichterung der nicht hardwarebezogenen Aufgaben wählt. Um den Rahmen nicht zu sprengen nur ein paar Beispiele.
:Physik:
:*[http://www.havok.com/ Havok]
:*[http://www.physicsengine.com/ Newton]
:*[http://www.ageia.com/novodex.html NovodeX]
:*[http://www.ode.org/ ODE]
:Fenster:
:*[http://www.gtk.org/ GTK]
:*[http://www.wxwidget.org/ wxWidget]
:*[[SDL]]
:*Win API (Windows)
:Kompression:
:*[http://www.zlib.net/ zLib]
:Künstliche Intelligenz:
:*[http://opensteer.sourceforge.net/ openSteer]

:6. Nun beachten wir unser eventuell eingeplantes Budget (normalerweise 0 ^_^) und gehen die Liste oben nochmal durch.

:7. Ein Programm teilt sich in der Regel in 3 Teilbereiche (im Bereich Software Engineering auch Pakete genannt), diese sind die GUI, die Programmlogik und die Datenbank.
:GUI:
:*Die GUI sorgt dafür, dass alle Informationen dem User grafisch dargestellt werden. Dabei geht dieses natürlich auch in die Gegenrichtung. Also der User gibt Informationen an den Computer.
:Logik:
:*Die Logik ist der größte Teil vom Programm, denn hier ist der ganze Code angesiedelt, der das Programm zum laufen bringt.
:Datenbank:
:*Das Datenbank Paket, ist der Part wo alle Daten, die das Programm benötigt, zwischengespeichert werden. Das wären z.B. Variablen, Texturdaten, Spielerinformationen und so weiter.

:Wer sich in der Material nur ausprobieren will, kann anfangen, so viel wie möglich selber zu programmieren. Wenn es aber darum geht, eine Engine zu schreiben, welche man auch benutzten will, dann sollte man versuchen, so viel Code wie möglich wieder zu verwerten. Viele Programmierer haben schon Funktionen, Strukturen und Lösungen geschrieben und diese gilt es so gut wie möglich wieder zu verwerten. Dies hat viele Vorteile, denn man spart Zeit, man kann sich sicher sein, dass der Code standardmässig läuft und man hat sich viel Zeit mit der Konzeptphase gespart. Man muss in der konstruktiven Entwicklung nicht mehr das Rad neu erfinden. Der Trend in der professionellen Programmierung geht seit vielen Jahren in diese Richtung. [[SDL]], [[OpenAL]], DirectX, [[OpenGL]], zLib und viele andere Bibliotheken haben sich so ihren Stellenwert erkämpft.

==Planung==
Wir gehen mal von ein "AllInOne Wonder" aus und nutzen FreePascal aufgrund der Plattformunabhängigkeit, SDL und sämtliche Zusatzpakete zur plattformunabhängigen Fensterinitialisierung sowie zum Laden von etlichen Bildformaten. Für die Soundausgabe werden wir aufgrund von Kostengründen auf OpenAL setzen. Für die Physik ist eine vorhandene Bibliothek wie zum Beispiel ODE zu favorisieren, da diese schon ausgereifter als eine selbst entwickelte ist. Doch kann im Gegenzug eine eigene Physik-Bibliothek eventuell schneller und viel schlanker sein, wenn man nur eine handvoll Dinge benötigt.

Geht's nun Los?

Na ja, nun kommt der wahrscheinlich unangenehmste Satz für alle:

Die Entwicklung einer Engine bedarf einer ausführlichen Planung, was kurz und knapp ein [[Softwarecycle]] bedeutet. Nun sollte man die einzelnen Schritte eines Softwarecycles abarbeiten und ganz am Ende, wenn viel Zeit rum ist, kann man dann endlich anfangen den Compiler flott zu machen. Kleiner Tipp: Macht euch die Mühe, da diese sich umso mehr auszahlt, je grösser das Projekt ist(für ein Packman Clon ist es aber eher Zeitverschwendung). Das Allerwichtigste bei großen Projekten ist, dass Aufgabenpakete/Module geschnürt werden. Diese sollten nach dem [[Blackbox]]-Prinzip erstellt werden. Dadurch können die Module unabhängig voneinander von verschiedenen Personen erstellt werden. Um so etwas realisieren zu können, ist natürlich klar, dass in die Planung der [[Schnittstelle|Schnittstellen]] zwischen den Modulen sehr viel Zeit eingesetzt werden sollte. Änderungen in den Modulen sind kein Problem, Änderungen an der Schnittstelle können Einfluss auf das gesamte Projekt haben. Eine Engine kann entweder auf Low-Level oder High-Level API aufsetzen, idealerweiser sollte man eine Zwischenlösung nutzen, hierzu finden Sie unter [[Low/High-Level|High/Low-Level API]] weitere Informationen.

In der Industrie verwendet man in größeren Engines Wrapper. Dieser ist dazu da, dass OpenGL/SDL und DirectX über eine eigene API angesteuert werden kann und somit ist es möglich die Engine mit den verschiedensten Plattformen (PC, Konsole, etc.) zurecht kommt. Laut einer neueren Umfrage schreiben 75% alle amerikanischen Publisher ihren Entwicklerteams vor, dass sie eine Engine mit genau dieser Eigenschaft nutzen. Des weiteren ist es auch immer häufiger, dass Publisher auf der ganzen Welt ihren Entwicklerteams vorschreiben, dass sie eine fertige Engine (Middleware) zu verwenden haben. Dies hat den Grund, dass der Publisher somit das Risiko eines Spiels vermindert und Geld spart - schließlich kostet das Entwickeln einer Engine eine große Summe an Geld und die Künstler sitzen währenddessen ohne Arbeit herum. Diese kalkulierten Kosten sind in der Summe höher als der Preis einer aktuellen Engine, wie zum Beispiel die "Vision" oder "Source" Engine.

Wenn Sie es noch nicht getan haben, dann schauen Sie sich am besten noch ein Buch oder Artikel über Pattern/Muster an. So sind [[Adapter_Muster|Adapter]], [[Singleton_Muster|Singleton]], [[Observer_Muster|Observer]] Muster sehr sinnvoll zu kennen.
So kann man z.B. für Materials, Texturen, Shader, Models, Animationen und alle anderen auf Daten basierte Komponenten mit dem [[Adapter Muster]] sehr flexibel sein.
Für ein SceneGraph kann man das Observer Muster prima anwenden und Singleton kann man für alle Manager verwenden.

{{Hinweis|Siehe die Tutorial Reihe [[Tutorial_Softwareentwicklung1|Softwareentwicklung]]}}

==Die ersten Schritte in eine nicht reelle Welt==
Nachdem man weiß, was das Projekt einmal enthalten soll, besteht der erste Schritt darin, Manager zu erstellen, die die Arbeit erleichtern. Bei 3D-Spielen ist z.B. ein Leveleditor kein Feature, was am Ende entwickelt wird, sondern der Editor ist fertig, noch bevor das Spiel getestet wird. Deshalb gibt es in Firmen Programmierer, die nichts anderes machen als Tools/Manager für die Erstellung der Inhalte zu fertigen. Dazu gehören:

# [[Leveleditoren]] um die "Welt" zu erstellen.
# '''Texturmanager''' um den Programmierern den Zugriff auf die Texturen so einfach wie möglich zu machen.
# '''Soundmanager''' (siehe vorheriges)
# '''Lademanager''' für eigene Dateiformate.

Nun ist es so weit, wir wissen was wir wollen und haben alles durchdacht.
Nun gilt es die einzelnen Module in die Tat um zu setzen.
Einige Module die es 3D Anwendungen/Spielen geben könnte:

'''Grundlagen:'''
#[[Template]]
#[[Kamera]]
#[[Schrift]]
#[[Input]] (Maus/Tastatur)
#[[Adapter Muster]]

'''Fortgeschrittene Grundlagen:'''
#[[Sound]]
#[[Physik]]
#[[Texturen]]
#[[Levelformat]]
#[[Modelformat]]
#[[Console]] (Laufzeit-Schnittstelle zur Engine)
#[[DGL GUI|GUI]] (Game User Interface)
#[[Netzwerk]]

'''Fortgeschritten:'''
#[[Shader]]
#[[Materials]]
#[[Packformate]]
#[[VFS]] (Virtual File System)
#[[Soundformat-Erweiterungen]]
#[[KI]]
#[[Script]]
#[[Scene Graph]]

Sieht doch eigentlich nach nicht so viel aus oder?

Doch der Schein trügt. In großen Firmen sitzen meist mehrere Programmierer, die in diesen Gebiet erfahren sind, an nur ein, maximal 2 Modulen. Wie ist es dann möglich, dass es trotzdem so viele Spiele/Engines gibt, die nicht von Firmen sind ?
#die Planung wird bei weitem nicht so groß ausfallen wie in Grossfirmen
#die Koordination von vielen Person ist sehr schwer und es kann zu großen Zeitlücken kommen
#meistens wird die Planung sowieso nicht in die Tat umzusetzen sein, es gibt immer ein Problem
#ein kleines Team kann sich im besten Fall gegenseitig hochpushen und zu mehr anspornen
#Großfirmen haben selten die Möglichkeit, mal einen Codefetzen in Foren zu setzen und verbessern zu lassen
#das Nutzen von Bibliotheken ist sehr zeitsparend

==Die Engine ist fertig oder doch nicht?==
Es gibt ein Unterschied zwischen der Entwicklung von einer Engine und der Entwicklung einer Engine für ein Spiel.
Die Engine für ein Spiel ist festgelegt und hat ein Endpunkt, was sie leisten soll.
Eine Engine als selbststehendes Projekt wird hingegen nie fertig, man kann sie immer wieder optimieren und erweitern.
Doch kommt der Punkt, wo die Qualität den Ansprüchen völlig ausreichend ist.
Man sollte nun noch überlegen, ob man eventuell ein Tool zur leichteren Handhabung der Engine entwickelt.
So kann ein GUI-Editor oder Material-Editor die Arbeit um vieles erleichtern, wenn es dann heißt die Engine auch zu nutzen. Diese Tools nennt man dann die Toolchain einer Engine und dort gehören dann neben den Editoren auch Compiler, Libs und Ressourcen hinzu.

Nun bleibt es nur noch zu sagen: viel Glück und Erfolg mit der Entwicklung einer eigenen Engine. Mögen die bereitgestellten Links zur Erleuchtung führen.

==Links==
[http://x-dream.neroneus.de X-Dream Engine]

[http://www.omorphia.de Projekt omorphia]

[http://andorra.sourceforge.net/ Andorra 2D]

[[Kategorie:Trampelpfad]]

Engine

2008-07-08T13:59:57Z

Yogu: Zweiter Link auf gleichen Artikel entfernt

'''Engine''' ist Englisch und bedeutet wörtlich übersetzt '''Motor'''.

In Bezug auf Grafik und Computerspiele wurde der Begriff Engine vor allem durch die ersten First Person Shooter geprägt. Die meisten Definitionen, die zu den Begriffen Rendering-, Grafik- und Game-Engine existieren, sind äusserst schwammig. Da sich jedoch in letzter Zeit der Begriff Engine auch im wissenschaftlichen Bereich weiter durchsetzt, findet sich nun auch die ein oder andere brauchbarere Definition wie zum Beispiel:

''In todays modularly constructed games, the games engine refers to that collection of modules of simulation code that do not directly specify the games behavior (game logic) or games environment (level data).'' 
[http://planetjeff.net/IndexDownloads/Lewis2002.pdf Game Engines in Scientific Research, CACM, Januar 2002]

Diese Definition besagt also, das eine Game Engine eine Bibliothek ist, die alles übernehmen ''kann'', was nicht direkt mit einem konkreten Spiel zusammenhängt. Der Streitpunkt ist nun, was direkt mit einem Spiel zusammen hängt und was nicht. Da viele Genres ganz andere Bedürfnisse an eine Game-Engine stellen, existieren auch hunderte verschiedene Engines.

Der Sinn hinter einer so strickten Trennung zwischen Game-Engine und eigentlichem Spiel, ist die Wiederverwendbarkeit ein und des selben Sourcecodes für mehrere Spiele und im kommerziellen Bereich zusätzlich noch der Verkauf der Engine an andere Produzenten. Aber auch aus der Sicht eines Softwareentwicklers bietet diese Trennung den Vorteil, dass man ein großes Projekt von vorne herein in zwei große Teilbereiche aufspaltet. Zusätzlich benötigt man bei einer Engine üblicherweise noch Editoren. Durch die Trennung von Spiel und Engine kann man die Engine auch für die Editorentwicklung verwenden, wodurch sich diese Modularisierung selbst bei der Entwicklung eines einzigen Spieles lohnt.

Eine Game-Engine setzt sich üblicherweise aus den folgenden Hauptbereichen zusammen:
*Grafik
*Sound
*[[Physik]]
*Netzwerk
*Eingabe
*Editoren
*[[KI|Künstliche Intelligenz]]

Da der Grafikbereich üblicherweise verhältnismäßig groß ist, gibt es auch eigene Grafik-Engines. Grafik-Engines sind also Game-Engines, die ausschließlich die Grafik behandeln, nicht die restlichen genannten Teilbereiche. Oder umgekehrt gesagt: eine Game-Engine besitzt eine eigene oder benutzt eine bestehende Grafik-Engine. [[Szenengraph|Szenengraphen]] fallen üblicherweise in die Kategorie Grafik-Engine, obwohl man von einer Engine häufig erst dann spricht, wenn irgend eine Art von Animation im Spiel ist, was bei Szenengraphen nicht zwingend der Fall sein muss. Diese Ansichten sind jedoch auch sehr vage und nicht unumstritten.

Nun existiert noch der Begriff Rendering-Engine, welcher üblicherweise verwendet wird, um noch eine Stufe tiefer zu gehen. Eine Rendering-Engine stellt nur eine sehr strikt definierte, jedoch sehr allgemein anwendbare Funktionalität zur Darstellung von 3D-Szenen zur Verfügung. Man könnte auch sagen, dass eine Rendering-Engine keine eigenen Entscheidungen trifft, welche sich auf das Aussehen der dargestellten Szene auswirken würden. Als bestes Beispiel sei hier [[LOD|Level of Detail]] genannt. Die Wahl des [[LOD|Level of Detail]] überlässt die Rendering-Engine fast ausschließlich den übergeordneten Programmteilen (beispielsweise der Grafik-Engine). [[OpenGL]] und [[Direct3D]] stellen wohl die bekanntesten Vertreter für Rendering-Engines dar. Wieder kann gesagt werden, dass eine Rendering-Engine ausschließlich die Darstellung eines konkreten [[Frame|Frames]] mit konkret gegebenen Parametern übernimmt. Und umgekehrt kann gesagt werden: eine Grafik-Engine besitzt eine eigene oder benutzt eine bestehende Rendering-Engine.

Nun wäre noch der Begriff 3D-Engine zu klären, welcher am vielfältigsten von allen eingesetzt wird. Üblicherweise handelt es sich dabei um einen Überbegriff für Game-, Grafik- und Rendering-Engine aber natürlich mit der Einschränkung, dass es sich um 3D- und nicht um 2D-Szenen handelt.

=Ressourcen=
*[http://gamearchitect.net/Articles/TheList.html The List], eine umfangreiche Auflistung der Teilgebiete, die bei einer Game-Engine beachtet werden können.
*[http://www.devmaster.net/engines/ 3D-Engines Liste], eine umfangreiche Sammlung von 3D Game- und Grafik- Engines.

glPolygonMode

2008-05-09T12:50:15Z

Yogu: /* Delphi-Spezifikation */ Delphi-Syntax hinzugefügt

= glPolygonMode =

== Name ==

'''glPolygonMode''' - wählt aus wie die einzelnen Polygone beim Rastern gezeichnet werden sollen.

== Delphi-Spezifikation ==
procedure '''glPolygonMode'''(''face'', ''mode'': GLenum);

== Parameter ==

<table border=1 rules=all>
<tr>
<td>''face''</td>
<td>Definiert auf welche Polygone mode angewendet werden soll. GL_FRONT bewirkt, dass mode nur auf nach Vorne gerichte Polygone angewandt wird. GL_BACK hingegen auf die nach hinten gerichteten. GL_FRONT_AND_BACK wirkt sich auf beide Seiten aus.</td>
</tr>
<tr>
<td>''mode''</td>
<td>Gibt an wie die betroffenen Polygone gezeichnet werden sollen. Mögliche Werte sind GL_POINT, GL_LINE und GL_FILL. </td>
</tr>
</table>

'''Standardgemäß''' wird '''GL_FILL''' auf die '''Vorder- und Rückseite''' aller Polygone angewandt.
 

== Beschreibung ==

glPolygonMode beinflusst wie Polygone bei der Rasterung gezeichnet werden. Auf welche Polygone es eine Auswirkung haben soll, kann man mit face festlegen.Der Polygonmodus wirkt sich nur beim letzten Rastervorgang auf die Polygone aus. Möglicherweise wurde der Eckpunkt des Polygones bereits beleuchtet oder durch das Culling beinflusst, bevor der mit glPolygonMode gesetze Effekt einsetzt.
<table rules=all>
<tr>
<td>GL_POINT</td>
<td>[[bild:Gl_point.png]]</td>
<td>Die Eckpunkte eines Polygones werden als einfache Punkte ohne Zwischenräume gezeichnet. Punktattribute wie GL_POINT_SIZE und GL_POINT_SMOOTH beinflussen die Wiedergabe der Punkte. Außer GL_POLYGONE_MODE haben andere Attribute keinerlei Auswirkung.</td>
</tr>
<tr>
<td>GL_LINE</td>
<td>[[bild:Gl_line.png]]</td>
<td>Miteinander verbundene Eckpunkte werden miteinander durch eine Linie verbunden. Attribute, die die Darstellung von Linien beinflussen wie zum Beispiel GL_LINE_WIDTH und GL_LINE_SMOOTH, verändern auch hier das Aussehen der Linien. Außer GL_POLYGONE_MODE haben andere Attribute keinerlei Auswirkung. Die Darstellung eines solch gezeichneten Models wird häufig als Drahtgitter-Model bezeichnet. Die Linien werden als zusammen gehörende Liniensegmente für das Stippling (siehe [[glLineStipple]] benutzt. Das heißt, das Tüpfelmuster wird zwischen den Linien nicht zurückgesetzt.
</td>
</tr>
<tr>
<td>GL_FILL</td>
<td>[[bild:Gl_fill.png]]</td>
<td>Das gesamte Polygon mitsamt seines Inneren also z.B. mit seiner Textur wird gezeichnet. Beachtet bitte, dass andere Attribute wie GL_POLYGON_STIPPLE und GL_POLYGON_SMOOTH ebenfalls die Wiedergabe des Polygons beinflussen könen. GL_FILL ist der Wert, der als Standard beim Initalisieren gesetzt wird.</td>
</tr>
</table>
 

==Weitere Beispiele==
Nachfolgend noch einige Beispiele zum PolygonMode. (Um Vorder- und Rückseite sichtbar zu machen wurde die Kugel mittels [[glClipPlane]] zerschnitten.)

<div align="center">
{| {{Prettytable_B1}}
! GL_FILL
! GL_LINE
|-
|[[Bild:Kugel_FILL.jpg]]
|[[Bild:Kugel_LINE.jpg]]
|-
! GL_POINT
! Vorderseite GL_FILL Rückseite GL_LINE
|-
|[[Bild:Kugel_POINT.jpg]]
|[[Bild:Kugel_MIX.jpg]]
|}
</div>

== Hinweise ==
Eckpunkte werden mit dem "Edge Flag" als an der Grenze anliegend markiert. Diese werden automatisch intern von OpenGL generiert, wenn die Polygone zerlegt werden. Wenn Ihr diese gezielt selbst setzen wollt, müsst ihr [[glEdgeFlag]] nutzen.

== Fehlermeldungen ==

GL_INVALID_ENUM wird generiert, wenn entweder face oder mode keine gültigen Werte waren. 
GL_INVALID_OPERATION wird generiert, wenn diese Funktion innerhalb eines glBegin/glEnd-Blocks aufgerufen wird.
 

== Zugehörige Wertrückgaben ==

[[glGet]] mit Token GL_POLYGON_MODE 

== Siehe auch ==

[[glBegin]], [[glEdgeFlag]], [[glLineStipple]], [[glLineWidth]], [[glPointSize]], [[glPolygonStipple]]

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

glDepthFunc

2008-05-08T18:24:27Z

Yogu: /* Parameter */ Unnötiges Komma vor 'und' entfernt

= glDepthFunc =
 
== Name ==
Die Funktion glDepthFunc legt fest, wann ein [[Fragment]] den [[Tiefentest]] im [[Tiefenpuffer]] besteht.

== Delphi-Spezifikation ==
'''procedure''' glDepthFunc(''func'': TGLenum);
 
== Parameter ==
{| border="1" rules="all"
! ''func''
| Legt die Tiefenvergleichsfunktion fest. Folgende symbolische Konstanten sind erlaubt: '''GL_NEVER, GL_LESS, GL_EQUAL, GL_LEQUAL, GL_GREATER, GL_NOTEQUAL, GL_GEQUAL''' und '''GL_ALWAYS'''. Voreingestellt ist '''GL_LESS'''.
|}
 

== Beschreibung ==
Die Funktion '''glDepthFunc''' legt fest, wann ein Fragment den Tiefentest im Tiefenpuffer besteht.

Der Parameter ''func'' legt die Tiefenvergleichsfunktion fest. Die Tiefenvergleichsfunktion ist eine Bedingung, die erfüllt sein muss, damit das entsprechende Pixel/Fragment gezeichnet wird.

Folgende Funktionen existieren:
{| {{Prettytable_B1}}
! GL_NEVER
| Neue Fragmente bestehen niemals den Vergleich.
|-
! GL_LESS
| Neue Fragmente bestehen den Vergleich, wenn sie einen geringeren Tiefenwert haben.
|-
! GL_EQUAL
| Neue Fragmente bestehen den Vergleich, wenn sie einen gleichgroßen Tiefenwert haben.
|-
! GL_LEQUAL
| Neue Fragmente bestehen den Vergleich, wenn sie einen kleineren oder gleichgroßen Tiefenwert haben.
|-
! GL_GREATER
| Neue Fragmente bestehen den Vergleich, wenn sie einen größeren Tiefenwert haben.
|-
! GL_NOTEQUAL
| Neue Fragmente bestehen den Vergleich, wenn sie einen anderen Tiefenwert haben.
|-
! GL_GEQUAL
| Neue Fragmente bestehen den Vergleich, wenn sie einen größeren oder gleichgroßen Tiefenwert haben.
|-
! GL_ALWAYS
| Neue Fragmente bestehen immer den Test.
|-
|}

== Hinweise ==
Der Standartwert von ''func'' ist '''GL_LESS'''. 
Nach der Initalisierung der GL ist der Tiefentest deaktiviert. Den Tiefentest kann man mit [[glEnable#GL_DEPTH_TEST|glEnable('''GL_DEPTH_TEST''')]] aktivieren.

== Fehlermeldungen ==
GL_INVALID_ENUM wird generiert wenn ''func'' ein ungültiger Wert übergeben wird. 
GL_INVALID_OPERATION wird generiert wenn '''glDepthFunc''' innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.
 
== Zugehörige Wertrückgaben ==
[[glGet]] mit Token GL_DEPTH_FUNC 
[[glIsEnabled]] mit Token GL_DEPTH_TEST
 
== Siehe auch ==
[[Tiefenpuffer]], [[glDepthRange]], [[glEnable]]

Hintergrundwissen: [[Tiefentest]]

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

glGetError

2008-05-08T16:51:51Z

Yogu: /* Fehlerwerte */ Groß- und Kleinschreibung, Zusammen- und Getrenntschreibung. Ein paar Fehler korrigiert

= glGetError =

== Name ==
'''glGetError''' - liefert Informationen über OpenGL-Fehler.

== Delphi-Spezifikation ==
'''Function''' glGetError : GLenum;

== Beschreibung ==
'''glGetError''' liefert den Wert des Error-Flags.
Jeder bemerkbare Fehler hat OpenGL-Intern einen numerischen Wert und einen symbolischen Namen. 
Wenn ein OpenGL-Fehler auftritt wird das Error-Flag auf den dafür vorgesehen Wert gesetzt. 
Sobald dies geschehen ist, werden keine anderen OpenGL-Fehler mehr registriert bis '''glGetError''' aufgerufen wird. 
(Das heißt, es wird immer nur der Fehler zurückgegeben, der zuerst auftrat.)

Durch den Aufruf von '''glGetError''' wird der Fehlercode zurückgegeben, und das
Error-Flag wieder auf '''GL_NO_ERROR''' gesetzt. 
Wenn ein Aufruf von '''glGetError''' '''GL_NO_ERROR''' zurückgibt, bedeutet dies, dass kein registrierbarer Fehler seit dem letzten Aufruf von '''glGetError'''(bzw. seit dem die GL initialisiert wurde) aufgetreten ist.

===Verteilte Implementationen===

Bei verteilten Implementationen, kann es mehrere Error_Flags geben. Sobald eins dieser Flags einen Fehler registriert hat, wird, bei einem Aufruf von '''glGetError''', der Wert dieses Flags zurück geliefert und das entsprechende Flag auf '''GL_NO_ERROR''' gesetzt. 
Wenn mehrere Flags einen Fehler registriert haben, liefert und löscht '''glGetError''' den Wert eines zufällig ausgewählten Flags. Aus diesem Grund sollte man '''glGetError''' in einer Schleife solange abrufen bis '''GL_NO_ERROR''' zurückgegeben wird.

===Fehlerwerte===
Der Initialisierungszustand des Error-Flags ist '''GL_NO_ERROR'''.

In der aktuellen OpenGL Version sind folgende Fehler definiert:

'''GL_NO_ERROR'''
:Kein Fehler ist aufgetreten.
:Der Wert dieser symbolischen Konstante ist garantiert immer 0.

'''GL_INVALID_ENUM'''
:Ein nicht akzeptierter Wert wurde einem numerischen Argument übergeben.
:Der fehlerhafte Befehl wird nicht ausgeführt und hat, abgesehen vom Setzen des Error_Flags keine weiteren Seiteneffekte.

'''GL_INVALID_VALUE'''
:Ein numerisches Argument ist außerhalb des vorgesehenen Intervalls. (out of range)
:Der fehlerhafte Befehl wird nicht ausgeführt und hat, abgesehen vom Setzen des Error_Flags keine weiteren Seiteneffekte.

'''GL_INVALID_OPERATION'''
:Der spezielle Befehl ist im momentanen Zustand von OpenGl nicht zulässig.
:Der fehlerhafte Befehl wird nicht ausgeführt und hat, abgesehen vom Setzen des Error_Flags keine weiteren Seiteneffekte.

'''GL_STACK_OVERFLOW'''
:Der entsprechende Befehl würde zum Überlaufen des Stacks führen. (Overflow)
:Der fehlerhafte Befehl wird nicht ausgeführt und hat, abgesehen vom Setzen des Error_Flags keine weiteren Seiteneffekte.
:(Dieser Fehler tritt vor allem dann auf, wenn es mehr Aufrufe von [[glPushMatrix]] als von [[glPopMatrix]] gibt.)

'''GL_STACK_UNDERFLOW'''
:Der entsprechende Befehl würde zum Unterlaufen des Stacks führen. (Underflow)
:Der fehlerhafte Befehl wird nicht ausgeführt und hat, abgesehen vom Setzen des Error_Flags keine weiteren Seiteneffekte.
:(Dieser Fehler tritt vor allem dann auf, wenn es mehr Aufrufe von [[glPopMatrix]] als von [[glPushMatrix]] gibt.)

'''GL_OUT_OF_MEMORY'''
:Es existiert nicht genug Speicher um den Befehl auszuführen.
:Der Status von OpenGL ist nach dem Auftrten dieses Fehlers undefiniert (abgesehen von den Error-Flags).

== Hinweise ==
Wenn ein Error-Flag gesetzt wird, ist nur im Falle '''GL_OUT_OF_MEMORY''' das Ergebnis der OpenGL undefiniert. In allen anderen Fällen wird der fehlerauslösende Befehl ignoriert und hat damit keine Auswirkungen auf den Status der GL oder den Inhalt des [[Framebuffer|Framebuffers]].

== Fehlermeldungen ==
'''GL_INVALID_OPERATION''' wird generiert wenn '''glGetError''' innerhalb eines
[[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

== Zugehörige Wertrückgaben ==
'''glGetError''' liefert ihnen den Wert des Fehlers zurück, der als erstes, seit dem letzen Aufruf von '''glGetError''', aufgetreten ist.

== Siehe auch ==
andere Wertrückgabefunktionen: [[glGet]]

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

TGA Bilder laden

2008-05-02T16:35:30Z

Yogu: Inhaltsverzeichnis angepasst & Kategorie: Tutorial

= TGA Bilder laden =

== TGA Dateien - Warum? ==

In diesem Artikel geht es um das manuelle Laden von Truevision
Bilddateien mit der allseits bekannten Endung ".tga".

Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen
auch schon in einer von "neueren" OpenGL-Implementierungen (konkret: 1.2) direkt benutzbaren
Ordnung vor.

Komprimierte TGA-Dateien lassen wir außen vor,
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise
schlecht.

== Landkarte und Kompass - oder besser GPS? ==

Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht
erraten - wir sind also auf fremde Dokumentation angewiesen.
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite
http://www.wotsit.org/.

Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von
TGA-Dateien zu geben scheint.

Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es
das gebräuchlichste Format ist.

== Definition eines Datentyps ==

Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?

Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.
Width of Image
Height of Image
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal
vorhanden ist.
Image Data Field - die eigentlichen Pixeldaten

Damit haben wir alles benötigte zusammen und können diese Informationen schon
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte
in unserem Dokument von wotsit):

<pascal>
type
TTGAFile = record
iType: byte; // should be 2
w, h: word; // Width, Height
bpp: byte; // Byte per Pixel
data: ^byte; // Pixels, dynamic length
end;
</pascal>

== Die Datei laden ==

Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".

Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.

<pascal>
function LoadTGA(const filename: string): TTGAFile;
var f: file; bytes: longword;
begin
assign(f, filename);
reset(f, 1);

// type
seek(f, 2);
blockread(f, result.iType, 1);

// w, h, bpp
seek(f, 12);
blockread(f, result.w, 5);
result.bpp := result.bpp div 8;

// data
bytes := result.w * result.h * result.bpp;
getmem(result.data, bytes);
seek(f, 18);
blockread(f, result.data^, bytes);

close(f);
end;
</pascal>

Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob
"bpp" den Wert 3 oder 4 erhalten hat).

== Datei rein - Textur raus ==

Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit
<pascal>
FreeMem(TGARecord.data);
</pascal>
wieder freizugeben!

<pascal>
procedure TGATexture(const filename: string; var TexID: longword);
var
tex: TTGAFile;
glFormat: longword;
begin
tex := LoadTGA(filename);
if tex.iType = 2 then
begin
glGenTextures(1, @TexID);
glBindTexture(GL_TEXTURE_2D, TexID);

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

if tex.bpp = 3 then glFormat := GL_BGR
else glFormat := GL_BGRA;

glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,
0, glFormat, GL_UNSIGNED_BYTE, tex.data);

FreeMem(tex.data);
end;
end;
</pascal>

Ich hoffe dieser Artikel war hilfreich (Ich will Feedback!) und wünsche euch
viel Spaß und Erfolg bei euren zukünftigen Projekten.

Gruß Waran.

[[Kategorie:Tutorial]]

Benutzer:Yogu

2008-05-02T11:20:59Z

Yogu: Rechtschreibfehler: Groß-/Kleinschreibung. fixed

Hallo,

ich möchte mich hier kurz vorstellen. Ich heiße Yogu (zumindest hier ;-)), programmiere seit dem 2. September 2004 in Delphi (ist zumindest meine älteste DPR), habe einen Monat davor mit [http://www.blitzbasic.com BlitzBasic] angefangen (und aufgehört!) und mehrere Delphi-Bücher durchgelesen, nochmal durchgelesen, gewartet, ein weiteres Mal durchgelesen und schließlich verstanden ;-)

Ich hab in allen Möglichen Programmierbereichen mal reingeschaut, und manche auch etwas weiter verfolgt, z. B. einen Movie-Manager, einen Audio-Player und auch mal eine "3D-Engine" mit Canvas.Pixels ;-).

Bevor ich auf OpenGL gestoßen bin, hab ich mit [http://www.genesis3d.com/ Genesis 3D] gearbeitet. Das war in einem [http://www.amazon.de/Game-Programming-Kids-Hans-Georg-Schumann/dp/3826608372 Buch] sehr anschaulich und einfach erklärt. Als ich dann jedoch vor kurzem angefangen habe, diese Engine etwas OOP-freundlicher zu verwalten, musste ich feststellen, dass sie doch Grenzen aufweist.

Und dann hat mich gestern jemand im [http://www.delphi-forum.de Delphi-Forum] (übrigens eine sehr gute Adresse im Thema Delphi-Probleme!) durch einen Post wieder auf OpenGL aufmerksam gemacht. Ja, vor einiger Zeit war ich hier schon mal - damals hatte ich aber noch sehr viel weniger Ahnung vom 3D-Programmieren.

Wenn du mir eine Nachricht hinterlassen willst, kannst du das in meiner [[Benutzer Diskussion:Yogu|Diskussionsseite]] tun.

Benutzer Diskussion:Yogu

2008-05-02T11:20:18Z

Yogu: Rechtschreibfehler: Groß-/Kleinschreibung. fixed

Hallo,

hier kannst du mir ([[Benutzer:Yogu|Yogu]]) eine Nachricht hinterlassen. Bitte füge deine Mitteilung an das Ende dieser Seite hinzu, indem du auf das [http://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Yogu&action=edit&section=new Plus-Zeichen] hinter ''Seite bearbeiten'' klickst.

Ich würde mich freuen, wenn du deine Nachricht freundlich verfasst und daran denkst, dass ich unfreundliche Mitteilungen nicht beachten werde.

Benutzer Diskussion:Yogu

2008-05-01T19:12:20Z

Yogu: Benutzerdiskussionsseite erstellt

Hallo,

hier kannst du mir ([[Benutzer:Yogu|Yogu]]) eine Nachricht hinterlassen. Bitte füge deine Mitteilung an das Ende dieser Seite hinzu, indem du auf das [http://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion:Yogu&action=edit&section=new Plus-Zeichen] hinter ''Seite bearbeiten'' klickst.

Ich würde mich freuen, wenn du Deine Nachricht freundlich verfasst und daran denkst, dass ich unfreundliche Mitteilungen nicht beachten werde.

Benutzer:Yogu

2008-05-01T19:11:14Z

Yogu: Benutzerseite erstellt

Hallo,

ich möchte mich hier kurz vorstellen. Ich heiße Yogu (zumindest hier ;-)), programmiere seit dem 2. September 2004 in Delphi (ist zumindest meine älteste DPR), habe einen Monat davor mit [http://www.blitzbasic.com BlitzBasic] angefangen (und aufgehört!) und mehrere Delphi-Bücher durchgelesen, nochmal durchgelesen, gewartet, ein weiteres Mal durchgelesen und schließlich verstanden ;-)

Ich hab in allen Möglichen Programmierbereichen mal reingeschaut, und manche auch etwas weiter verfolgt, z. B. einen Movie-Manager, einen Audio-Player und auch mal eine "3D-Engine" mit Canvas.Pixels ;-).

Bevor ich auf OpenGL gestoßen bin, hab ich mit [http://www.genesis3d.com/ Genesis 3D] gearbeitet. Das war in einem [http://www.amazon.de/Game-Programming-Kids-Hans-Georg-Schumann/dp/3826608372 Buch] sehr anschaulich und einfach erklärt. Als ich dann jedoch vor kurzem angefangen habe, diese Engine etwas OOP-freundlicher zu verwalten, musste ich feststellen, dass sie doch Grenzen aufweist.

Und dann hat mich gestern jemand im [http://www.delphi-forum.de Delphi-Forum] (übrigens eine sehr gute Adresse im Thema Delphi-Probleme!) durch einen Post wieder auf OpenGL aufmerksam gemacht. Ja, vor einiger Zeit war ich hier schon mal - damals hatte ich aber noch sehr viel weniger Ahnung vom 3D-Programmieren.

Wenn du mir eine Nachricht hinterlassen willst, kannst Du das in meiner [[Benutzer Diskussion:Yogu|Diskussionsseite]] tun.