DGL Wiki - Benutzerbeiträge [de]

Tutorial Raytracing - Grundlagen I

2006-12-25T16:41:13Z

Luketheduke: /* Die Griechische Vorstellung */

= Tutorial Raytracing - Grundlagen I =
[[Bild:Tutorial_RaytracingI_teaser.jpg|center]]
== Einführung ==
Da melde ich mich mal wieder zurück mit einem kleinen Tutorial bezüglich Raytracing. Ihr sollt ja gelegentlich was neues lernen. Es ist zwar etwas schade, daß nur noch selten Tutorials aus der Community kommen - ich hoffe immernoch, daß sich das irgendwann wieder ändern wird. Und alle die bislang Tutorials geschrieben haben, mussten ja irgendwann ihr erstes schreiben - also nur Mut (mein allererstes war im Übrigen das 1. Tutorial aus der Terrain-Reihe). Nunja. Was hat es also mit dem Raytracing auf sich? Und warum heisst dieses Tutorial Grundlagen I? Ich will es euch erklären. Beim Raytracing verfolgt man im Gegensatz zum Rastern wie es etwa OpenGl oder Direct3D machen, einen anderen Ansatz. Statt Objekte oberflächlich in Polygone zu zerschneiden und sie dann auf den Bildschirm per Z-Buffer zu projezieren, wirft die Kamera Strahlen in die Szenerie und auf jedem Strahl prüft man, ob sich ein Objekt mit dem Strahl schneidet. Man verliert dadurch sehr deutlich Geschwindigkeit: die wenigsten Raytracer sind so schnell, dass man interaktiv damit arbeiten kann. Wozu also ist dann Raytracing gut? Man kann im Raytracer hoch realistisch wirkende Bilder erzeugen und auch Verfahren verwenden, die im Rasterizer nicht oder kaum nachzubauen sind - die gute alte Grafikkarte muss dabei nicht völlig unnütz werden: Diese besitzen sehr flotte und massiv parallele Geometrie-Einheiten, die auch im Raytracer Verwendung finden können - dies ist aber etwas zu speziell für unser kleines Tutorial und vielleicht auch nicht das, was man in seinem ersten Raytracer implementieren würde. Was sich im Bereich interaktiver Grafik allerdings anbietet, ist den Raytracer ein wenig umzumodeln und mit ihm statische Lightmaps erzeugen oder ihn zur Selection missbrauchen. Das einzige Problem welches wir dabei haben: Wir müssen alles von Grund auf zusammenbasteln - nicht so schön, wie bei OpenGl, wo man nach ein paar Stunden recht ansehnliche Bilder samt Beleuchtung zeichnen kann. Wir werden da wohl etwas länger brauchen, aber ewig wird es auch nicht dauern - und schliesslich musste OpenGl ja auch erst einmal designed werden. Andere Dinge werden sich dagegen deutlich leichter implementieren lassen als mit OpenGl, so sind etwa Schatten im Raytracer ein Kinderspiel - im Rasterizer können sie richtig arbeitsintensiv werden.

== Die griechische Vorstellung ==
[[Bild:Tutorial_RaytracingI_griechisch.jpg|right]]
Die Griechen hatten eine etwas sonderbare Vorstellung vom Sehen: Sie stellten sich vor, dass aus ihren Augen Strahlen kommen, die dann auf die Umgebung treffen und quasi Nachricht an das Auge geben, was sie getroffen haben, wie weit weg es ist und welche Farbe es hat. Das ist in etwa das was auch ein Raytracer macht. Wir wollen das erst einmal im Hinterkopf behalten und uns zunächst mit Strahlen genauer auseinandersetzen. Danach werden wir Kugeln mit diesen Strahlen schneiden und eine passende perspektivische Kamera entwerfen. Schließlich werden wir einen sehr einfachen Raytracer schreiben, und ihm anschließend noch Ebenen als Objekte näherbringen, weil Kugeln alleine doch etwas langweilig sind.

== Strahlen ==
Was ist also ein Strahl? Ein Strahl hat einen Ursprung, an dem er beginnt, und eine Richung, in die er verläuft. Wer in der Schule in Geometrie aufgepasst hat, kennt dieses Objekt sicher auch noch als Halbgerade. Da wir später damit rechnen werden, müssen wir den Strahl in eine schöne Formel packen:
[[Bild:Tutorial_RaytracingI_strahlgleichung.png|center]]
Die Punkte auf unserem Strahl r sind also parametrisiert durch t, welches die
Zahlen von 0 bis unendlich durchläuft. Der Ursprung des Strahles ist o und seine
Richung d. Somit kennen wir alle Punkte auf dem Strahl.

Um nun zu prüfen, ob ein Strahl nun ein Objekt trifft, beginnen wir bei t = 0 und laufen alle Punkte ab, bis wir bei t = unendlich angekommen ... ... ... Nein so machen wir das natürlich nicht - funktionieren würde es zwar, würde aber unendlich lange dauern: Nicht gerade das, was wir uns unter schnell vorstellen.

Bevor wir weitermachen, sollten wir unseren Strahl gleich in
etwas Code verpacken, schließlich wollen wir uns ja einen Raytracer schreiben:
<cpp>public struct Ray
{
public Vertex3 Origin;
public Vertex3 Direction;

public Vertex3 Evaluate (double t)
{
return Origin + t * Direction;
}
}</cpp>

Zurück zu unserem Problem: Wir müssten also unendlich lange darauf warten, bis unser Raytracer das Objekt gefunden hat, mit dem sich der momentan betrachtete Strahl schneidet. Viel schneller geht die Sache, wenn wir vorher beschließen, welche Objekte wir anzeigen können wollen. Für den Anfang wollen wir uns mit sehr einfachen Objekten begnügen: Kugeln. Sie sind schnell berechnet und werden für erste Experimente ausreichen.

== Kugeln ==
Erinnerung: Eine Kugel ist definiert durch ihren Mittelpunkt und ihren Radius r. Setzt man den Mittelpunkt auf den Ursprung des Koordinatensystems, dann sind die Punkte auf der Oberfläche O unserer Kugel gerade die Punkte, die vom Ursprung den Abstand r haben. Die uns interessierende Bedingung wird so zu ||p|| = r für Punkte p auf O. Die Gleichung kann man schadlos quadrieren und statt der Vektorlänge ||p|| bekommt man das ohne Wurzel ziehen zu berechnende [[Standard Skalarprodukt|Skalarprodukt]] von p mit sich selbst:
[[Bild:Tutorial_RaytracingI_skalprodpp.png|center]]
Setzt man hierein die obige Gleichung für den Strahl, ergibt sich:
[[Bild:Tutorial_RaytracingI_radsqr.png|center]]
Und damit:
[[Bild:Tutorial_RaytracingI_radsqr2.png|center]]
Da die Richtung o und d unseres Strahls bekannt sind, haben wir eine quadratische Gleichung vor der Nase, die wir mittels Mitternachtsformel lösen können:
[[Bild:Tutorial_RaytracingI_mitternacht.png|center]]
Anhand der Diskriminante D, also dem Teil des obigen Ausdrucks, der unter der Wurzel steht, können wir entscheiden, ob der Strahl die Kugel trift. Ist nämlich D < 0, so kann man in den reelen Zahlen die Wurzel nicht berechnen. Ist D = 0, so gibt es genau eine Lösung der Schnittgleichung und für D > 0 schneidet der Strahl die Kugel genau 2 mal. Da wir unseren Strahl nur für positive Parameter t definiert haben, sollten wir die errechneten Schnittpunkte t1 und t2 noch daraufhin untersuchen:
<cpp>public double RayIntersect ( Ray ray )
{
double boundingSquare = sphereRadius * sphereRadius ;
ray.Origin -= Position;
double a, b, c;
a = ray.Direction.DotDot ;
// DotDot ^= Skalarprod mit sichselbst : <d, d>
b = 2 * ( ray.Origin * ray.Direction );
// * ^= normales Skalarprod
c = ray.Origin.DotDot - boundingSquare;

double t1 , t2 ;
int roots = CalcQuadricRoots (a, b, c, out t1, out t2) ;

if (roots > 0)
return t1 >= 0 ? t1 : t2 ;
// kleinsterpositiver pos. Wert aus t1, t2
else
return -1; // Kein Schnittpunkt
}</cpp>
Einen kleinen Haken hat die Sache jedoch: Analytisch, d.h. per Stift und Papier, lässt sich mit der Mitternachtsformel wunderbar rechnen. Am Computer neigt sie zu Fehlern, was ganz allein an dem ± liegt. So führt man verlässlich eine Subtraktion durch, wenn D > 0 ist - und Subtraktionen sind reines Gift für die Genauigkeit bei numerischen Rechnungen. Durch kleine Umformungen und das Bestimmen eines Vorzeichens, können wir das Problem umgehen:

== Quadratische Gleichungen ==
Hat man also eine Quadratische Gleichung in der allgemeinen Form:
[[Bild:Tutorial_RaytracingI_quadratisch.png|center]]
dann bestimmt man die Nullstellen am besten durch:
[[Bild:Tutorial_RaytracingI_quadratisch_numerisch.png|center]]
Bei der Auswertung von q wird so sicherlich echt addiert, weil zu b eine Zahl gleichen Vorzeichens summiert wird. Dass der Wert für t1 stimmt, hat man dann auch sehr leicht nachgerechnet, wohingegen t2 in wildes Rumgeschiebe der Formel ausartet und sich erst recht spät sign(b) herauswerfen lässt. Ich erspare euch nähere Erläuterungen ;-) Ein bischen Quellcode hierzu:

<cpp>public static int CalcQuadricRoots(double a, double b, double c, out double x1, out double x2)
{
double determinant = b * b - 4 * a * c;
if (determinant < 0)
{
x1 = 0.0;
x2 = 0.0;
return 0;
}
determinant = Math.Sqrt(determinant);
double q = -0.5 * (b + PSgn(b) * determinant);
// Psgn: gives - 1 if b < 0 and 1 if b >= 0.
// so no zero as normal sgn would give us.
x1 = q / a;
x2 = c / q;
// Sort by value
if (x1 > x2)
{
q = x2; x2 = x1; x1 = q;
}
return x1 == x2 ? 1 : 2;
}</cpp>
Die Funktion speichert die Nullstellen in den Variablen x1, x2 dem Wert nach sortiert ab und gibt die Anzahl der Nullstellen zurück.
Da wir jetzt bereits bestimmen können, wo und wie oft unser Strahl die Kugel trift, können wir, nachdem wir uns noch einen Strahlenwerfer, (also eine Kamera) konstruiert haben, unseren ersten Raytracer bauen.

== Perspektivische Kamera ==
Jeder, der sich mit OpenGL auskennt, wird bei der Konstruktion einer perspektivischen Kamera gleich schreien, daß man dazu doch einfach nur eine Projektionsmatrix braucht, die man sich ganz einfach aus der OpenGL Spezifikation stibitzen kann. Falsch gedacht: Ein Raytracer ist kein Rasterizer: Wir brauchen keine Projektionsmatrizen, noch nicht einmal Matrizen. Die perspektivische Kamera eines Ray-Tracers lässt sich direkt nach vorn heraus entwerfen:

[[Bild:Tutorial_RaytracingI_perspektivisch.png|center]]

Unrotiert und unverschoben soll unsere Kamera in die Tiefenrichtung z blicken. Dabei wird unser Bildschirm durch die Parameter links, rechts, oben und unten beschrieben. Ist die Auflösung des Bildschirms in X wie in Y-Richtung bekannt, so kann man leicht die Richtung d des Vektors bestimmen, der vom Betrachter auf den Bildschirm zeigt. Sofort bekommt man so einen Strahl, wenn man als Anfangspunkt o die Position des Betrachters wählt:

<cpp>public Ray ShootRay ( int x , int y )
{
Ray result = new Ray();
result.Origin = Position;

double xpart , ypart ;
xpart = ( ( double ) x ) / (double ) widthpixels;
ypart = ( ( double ) y ) / (double ) heightpixels;

xpart = left + xpart * ( right - left ) ;
ypart = top + ypart * ( bottom - top ) ;

result.Direction.x = xpart;
result.Direction.y = ypart;
result.Direction.z = 1.0;

/* if ( Transformation != null )
{
result.Direction =
Transformation.Apply( result.Direction );
} */
result.Direction.Normalize();
return result;
}</cpp>
Die auskommentierte if-Abfrage soll vorerst nicht stören. Ihr wird später leben eingehaucht, wenn wir dem Raytracer Verschiebungen,
Rotationen, Skalierungen, Scheerungen, u.s.w. einbauen.

== Einfacher Raycaster ==
[[Bild:Tutorial_RaytracingI_depthcasting.jpg|right]]
Damit sind wir dann auch schon soweit, daß wir unsere ersten Gehversuche in Sachen Raytracing wagen können. Für jedes Pixel im Bild werfen wir mittels ShootRay einen Strahl und prüfen, ob dieser die Kugeln in unserer Szene schneidet. Wenn ja, merken wir uns den nähestes dieser Schnittpunkte und weisen ihm einen Farbwert zu. So erhalten wir ein Bild, das in etwa die Informationen wieder gibt, die OpenGl in seinem Tiefenpuffer speichern würde. Ich gebe zu, das ist nicht hochgradig spannend, aber solange wir uns noch nicht eingehender mit Licht und Shading beschäftigt haben, können wir auch nicht mehr erwarten - und wir haben beim Raytracing ja leider das Problem, daß wir ganz von vorne anfangen müssen:

<cpp>public RaytraceImage ( int width , int height )
{
// near und far sind die Werte fuer den Bereich ,
// von dem Tiefeninformationen abgebildet werden
for ( int x = 0; x < width; x++) {
for ( int y = 0 ; y < height; y++) {
Ray shoot = ShootRay (x , y);
double maxdist = double.Infinity;

foreach (Kugel obj in SichtbareKugeln) {
double hitdist = obj.RayIntersect(shoot) ;
if (hitdist > 0 && maxdist > hitdist)
maxdist = hitdist;
}

if (maxdist < double.Infinity) {
SetColor(x, y, Colors.Gray (Math.Min(Math .Max(0,
(maxdist - near) / ( near - far ))), 1.0)) ;
}
else
SetColor(x, y, BackgroundColor);
}
}
}</cpp>
Eine kleine Anmerkung noch: Da wir uns noch nicht über Transformationen Gedanken gemacht haben, und unsere Kugeln bislang am Nullpunkt aufgehäng sind, können wir diese noch nicht positionieren - sprich es wird höchstens die größte Kugel sichtbar, weil alle weiteren verdeckt sind. Das lässt sich beheben, indem man vor dem Test auf Schnitt vom Ursprung des entsprechenden Strahles, die Position der Kugel abzieht.

== Ebenen ==
Mit Kugeln kann man zwar so einiges darstellen, aber nur Kugeln sind vielleicht doch etwas langweilig. Wir wollen deshalb noch Ebenen implementieren. Am besten betrachten wir diese dazu in der Normalform, d.h. die Ebene wird allein durch ihre Flächennormale angegeben. Für Punkte auf der Ebene gilt dann:
[[Bild:Tutorial_RaytracingI_ebenengleichung.png|center]]
Setzt man nun in x unseren Strahl ein, ergibt sich:
[[Bild:Tutorial_RaytracingI_ebenenrechnung.png|center]]
Ist <d,n>=0, dann gibt es keine Lösung, sonst genau eine.

Welche Objekte eignen sich sonst gut zum Raytracing? ... Alle Objekte, die sich in kartesischen Koordinaten durch eine Gleichung der Form [[Bild:Tutorial_RaytracingI_kartesisch.png|center]] darstellen lassen. In (x,y,z) setzt man seinen Strahl r(t) ein und versucht nach t aufzulösen. In einigen Fällen wird dieses Problem leider kaum zu lösen sein: man kommt dann um den Einsatz von numerischen Verfahren nicht herum. Ich werde versuchen, in Folgetutorials noch ein paar weitere, interessante Objekte vorzustellen, die sich direkt lösen lassen und wenn ich viel Geduld habe, vielleicht auch einmal einen eigenen Artikel bezüglich numerischer Verfahren.

== Vorschau ==
Damit sind wir auch schon wieder soweit. Die ersten Grundlagen sind abgehandelt, aber wirklich überzeugt sind wir vom Raytracing noch nicht. Damit sich das ändert, sind weitere Tutorials in Planung: Wir wollen uns dann mit Licht und Normalen beschäftigen. Ausserdem sind Reflektionen und Transparenz spannende Dinge, denen wir uns widmen können. Wir wollen ausserdem unsere Objekte transformieren, scheeren, rotieren, ... Es bleibt also noch einiges im Bereich Raytracing zu tun, was hier nicht behandelt wurde.

Bis es soweit ist, könnt ihr euch ja selbst schonmal ein paar Gedanken zum Thema machen oder euch doch lieber in die Weiten von OpenGl flüchten.

'''[[Benutzer:Nico Michaelis|Nico Michaelis]]'''

Tutorial Raytracing - Grundlagen I

2006-12-25T16:39:43Z

Luketheduke: /* Einführung */

= Tutorial Raytracing - Grundlagen I =
[[Bild:Tutorial_RaytracingI_teaser.jpg|center]]
== Einführung ==
Da melde ich mich mal wieder zurück mit einem kleinen Tutorial bezüglich Raytracing. Ihr sollt ja gelegentlich was neues lernen. Es ist zwar etwas schade, daß nur noch selten Tutorials aus der Community kommen - ich hoffe immernoch, daß sich das irgendwann wieder ändern wird. Und alle die bislang Tutorials geschrieben haben, mussten ja irgendwann ihr erstes schreiben - also nur Mut (mein allererstes war im Übrigen das 1. Tutorial aus der Terrain-Reihe). Nunja. Was hat es also mit dem Raytracing auf sich? Und warum heisst dieses Tutorial Grundlagen I? Ich will es euch erklären. Beim Raytracing verfolgt man im Gegensatz zum Rastern wie es etwa OpenGl oder Direct3D machen, einen anderen Ansatz. Statt Objekte oberflächlich in Polygone zu zerschneiden und sie dann auf den Bildschirm per Z-Buffer zu projezieren, wirft die Kamera Strahlen in die Szenerie und auf jedem Strahl prüft man, ob sich ein Objekt mit dem Strahl schneidet. Man verliert dadurch sehr deutlich Geschwindigkeit: die wenigsten Raytracer sind so schnell, dass man interaktiv damit arbeiten kann. Wozu also ist dann Raytracing gut? Man kann im Raytracer hoch realistisch wirkende Bilder erzeugen und auch Verfahren verwenden, die im Rasterizer nicht oder kaum nachzubauen sind - die gute alte Grafikkarte muss dabei nicht völlig unnütz werden: Diese besitzen sehr flotte und massiv parallele Geometrie-Einheiten, die auch im Raytracer Verwendung finden können - dies ist aber etwas zu speziell für unser kleines Tutorial und vielleicht auch nicht das, was man in seinem ersten Raytracer implementieren würde. Was sich im Bereich interaktiver Grafik allerdings anbietet, ist den Raytracer ein wenig umzumodeln und mit ihm statische Lightmaps erzeugen oder ihn zur Selection missbrauchen. Das einzige Problem welches wir dabei haben: Wir müssen alles von Grund auf zusammenbasteln - nicht so schön, wie bei OpenGl, wo man nach ein paar Stunden recht ansehnliche Bilder samt Beleuchtung zeichnen kann. Wir werden da wohl etwas länger brauchen, aber ewig wird es auch nicht dauern - und schliesslich musste OpenGl ja auch erst einmal designed werden. Andere Dinge werden sich dagegen deutlich leichter implementieren lassen als mit OpenGl, so sind etwa Schatten im Raytracer ein Kinderspiel - im Rasterizer können sie richtig arbeitsintensiv werden.

== Die Griechische Vorstellung ==
[[Bild:Tutorial_RaytracingI_griechisch.jpg|right]]
Die Griechen hatten eine etwas sonderbare Vorstellung vom Sehen: Sie stellten sich vor, daß aus ihren Augen Strahlen kommen, die dann auf die Umgebung treffen und dann quasi Nachricht an das Auge geben, was sie getroffen haben, wie weit weg es ist und welche Farbe es hat. Das ist in etwa das, was auch ein Raytracer macht. Wir wollen das erst einmal im Hinterkopf behalten und uns zuerst mit Strahlen genauer auseinandersetzen. Danach werden wir Kugeln mit diesen Strahlen schneiden und eine passende perspektivische Kamera entwerfen. Schließlich werden wir einen sehr einfachen Raytracer schreiben, und ihm anschließend noch Ebenen als Objekte näherbringen, weil Kugeln alleine doch etwas langweilig sind.

== Strahlen ==
Was ist also ein Strahl? Ein Strahl hat einen Ursprung, an dem er beginnt, und eine Richung, in die er verläuft. Wer in der Schule in Geometrie aufgepasst hat, kennt dieses Objekt sicher auch noch als Halbgerade. Da wir später damit rechnen werden, müssen wir den Strahl in eine schöne Formel packen:
[[Bild:Tutorial_RaytracingI_strahlgleichung.png|center]]
Die Punkte auf unserem Strahl r sind also parametrisiert durch t, welches die
Zahlen von 0 bis unendlich durchläuft. Der Ursprung des Strahles ist o und seine
Richung d. Somit kennen wir alle Punkte auf dem Strahl.

Um nun zu prüfen, ob ein Strahl nun ein Objekt trifft, beginnen wir bei t = 0 und laufen alle Punkte ab, bis wir bei t = unendlich angekommen ... ... ... Nein so machen wir das natürlich nicht - funktionieren würde es zwar, würde aber unendlich lange dauern: Nicht gerade das, was wir uns unter schnell vorstellen.

Bevor wir weitermachen, sollten wir unseren Strahl gleich in
etwas Code verpacken, schließlich wollen wir uns ja einen Raytracer schreiben:
<cpp>public struct Ray
{
public Vertex3 Origin;
public Vertex3 Direction;

public Vertex3 Evaluate (double t)
{
return Origin + t * Direction;
}
}</cpp>

Zurück zu unserem Problem: Wir müssten also unendlich lange darauf warten, bis unser Raytracer das Objekt gefunden hat, mit dem sich der momentan betrachtete Strahl schneidet. Viel schneller geht die Sache, wenn wir vorher beschließen, welche Objekte wir anzeigen können wollen. Für den Anfang wollen wir uns mit sehr einfachen Objekten begnügen: Kugeln. Sie sind schnell berechnet und werden für erste Experimente ausreichen.

== Kugeln ==
Erinnerung: Eine Kugel ist definiert durch ihren Mittelpunkt und ihren Radius r. Setzt man den Mittelpunkt auf den Ursprung des Koordinatensystems, dann sind die Punkte auf der Oberfläche O unserer Kugel gerade die Punkte, die vom Ursprung den Abstand r haben. Die uns interessierende Bedingung wird so zu ||p|| = r für Punkte p auf O. Die Gleichung kann man schadlos quadrieren und statt der Vektorlänge ||p|| bekommt man das ohne Wurzel ziehen zu berechnende [[Standard Skalarprodukt|Skalarprodukt]] von p mit sich selbst:
[[Bild:Tutorial_RaytracingI_skalprodpp.png|center]]
Setzt man hierein die obige Gleichung für den Strahl, ergibt sich:
[[Bild:Tutorial_RaytracingI_radsqr.png|center]]
Und damit:
[[Bild:Tutorial_RaytracingI_radsqr2.png|center]]
Da die Richtung o und d unseres Strahls bekannt sind, haben wir eine quadratische Gleichung vor der Nase, die wir mittels Mitternachtsformel lösen können:
[[Bild:Tutorial_RaytracingI_mitternacht.png|center]]
Anhand der Diskriminante D, also dem Teil des obigen Ausdrucks, der unter der Wurzel steht, können wir entscheiden, ob der Strahl die Kugel trift. Ist nämlich D < 0, so kann man in den reelen Zahlen die Wurzel nicht berechnen. Ist D = 0, so gibt es genau eine Lösung der Schnittgleichung und für D > 0 schneidet der Strahl die Kugel genau 2 mal. Da wir unseren Strahl nur für positive Parameter t definiert haben, sollten wir die errechneten Schnittpunkte t1 und t2 noch daraufhin untersuchen:
<cpp>public double RayIntersect ( Ray ray )
{
double boundingSquare = sphereRadius * sphereRadius ;
ray.Origin -= Position;
double a, b, c;
a = ray.Direction.DotDot ;
// DotDot ^= Skalarprod mit sichselbst : <d, d>
b = 2 * ( ray.Origin * ray.Direction );
// * ^= normales Skalarprod
c = ray.Origin.DotDot - boundingSquare;

double t1 , t2 ;
int roots = CalcQuadricRoots (a, b, c, out t1, out t2) ;

if (roots > 0)
return t1 >= 0 ? t1 : t2 ;
// kleinsterpositiver pos. Wert aus t1, t2
else
return -1; // Kein Schnittpunkt
}</cpp>
Einen kleinen Haken hat die Sache jedoch: Analytisch, d.h. per Stift und Papier, lässt sich mit der Mitternachtsformel wunderbar rechnen. Am Computer neigt sie zu Fehlern, was ganz allein an dem ± liegt. So führt man verlässlich eine Subtraktion durch, wenn D > 0 ist - und Subtraktionen sind reines Gift für die Genauigkeit bei numerischen Rechnungen. Durch kleine Umformungen und das Bestimmen eines Vorzeichens, können wir das Problem umgehen:

== Quadratische Gleichungen ==
Hat man also eine Quadratische Gleichung in der allgemeinen Form:
[[Bild:Tutorial_RaytracingI_quadratisch.png|center]]
dann bestimmt man die Nullstellen am besten durch:
[[Bild:Tutorial_RaytracingI_quadratisch_numerisch.png|center]]
Bei der Auswertung von q wird so sicherlich echt addiert, weil zu b eine Zahl gleichen Vorzeichens summiert wird. Dass der Wert für t1 stimmt, hat man dann auch sehr leicht nachgerechnet, wohingegen t2 in wildes Rumgeschiebe der Formel ausartet und sich erst recht spät sign(b) herauswerfen lässt. Ich erspare euch nähere Erläuterungen ;-) Ein bischen Quellcode hierzu:

<cpp>public static int CalcQuadricRoots(double a, double b, double c, out double x1, out double x2)
{
double determinant = b * b - 4 * a * c;
if (determinant < 0)
{
x1 = 0.0;
x2 = 0.0;
return 0;
}
determinant = Math.Sqrt(determinant);
double q = -0.5 * (b + PSgn(b) * determinant);
// Psgn: gives - 1 if b < 0 and 1 if b >= 0.
// so no zero as normal sgn would give us.
x1 = q / a;
x2 = c / q;
// Sort by value
if (x1 > x2)
{
q = x2; x2 = x1; x1 = q;
}
return x1 == x2 ? 1 : 2;
}</cpp>
Die Funktion speichert die Nullstellen in den Variablen x1, x2 dem Wert nach sortiert ab und gibt die Anzahl der Nullstellen zurück.
Da wir jetzt bereits bestimmen können, wo und wie oft unser Strahl die Kugel trift, können wir, nachdem wir uns noch einen Strahlenwerfer, (also eine Kamera) konstruiert haben, unseren ersten Raytracer bauen.

== Perspektivische Kamera ==
Jeder, der sich mit OpenGL auskennt, wird bei der Konstruktion einer perspektivischen Kamera gleich schreien, daß man dazu doch einfach nur eine Projektionsmatrix braucht, die man sich ganz einfach aus der OpenGL Spezifikation stibitzen kann. Falsch gedacht: Ein Raytracer ist kein Rasterizer: Wir brauchen keine Projektionsmatrizen, noch nicht einmal Matrizen. Die perspektivische Kamera eines Ray-Tracers lässt sich direkt nach vorn heraus entwerfen:

[[Bild:Tutorial_RaytracingI_perspektivisch.png|center]]

Unrotiert und unverschoben soll unsere Kamera in die Tiefenrichtung z blicken. Dabei wird unser Bildschirm durch die Parameter links, rechts, oben und unten beschrieben. Ist die Auflösung des Bildschirms in X wie in Y-Richtung bekannt, so kann man leicht die Richtung d des Vektors bestimmen, der vom Betrachter auf den Bildschirm zeigt. Sofort bekommt man so einen Strahl, wenn man als Anfangspunkt o die Position des Betrachters wählt:

<cpp>public Ray ShootRay ( int x , int y )
{
Ray result = new Ray();
result.Origin = Position;

double xpart , ypart ;
xpart = ( ( double ) x ) / (double ) widthpixels;
ypart = ( ( double ) y ) / (double ) heightpixels;

xpart = left + xpart * ( right - left ) ;
ypart = top + ypart * ( bottom - top ) ;

result.Direction.x = xpart;
result.Direction.y = ypart;
result.Direction.z = 1.0;

/* if ( Transformation != null )
{
result.Direction =
Transformation.Apply( result.Direction );
} */
result.Direction.Normalize();
return result;
}</cpp>
Die auskommentierte if-Abfrage soll vorerst nicht stören. Ihr wird später leben eingehaucht, wenn wir dem Raytracer Verschiebungen,
Rotationen, Skalierungen, Scheerungen, u.s.w. einbauen.

== Einfacher Raycaster ==
[[Bild:Tutorial_RaytracingI_depthcasting.jpg|right]]
Damit sind wir dann auch schon soweit, daß wir unsere ersten Gehversuche in Sachen Raytracing wagen können. Für jedes Pixel im Bild werfen wir mittels ShootRay einen Strahl und prüfen, ob dieser die Kugeln in unserer Szene schneidet. Wenn ja, merken wir uns den nähestes dieser Schnittpunkte und weisen ihm einen Farbwert zu. So erhalten wir ein Bild, das in etwa die Informationen wieder gibt, die OpenGl in seinem Tiefenpuffer speichern würde. Ich gebe zu, das ist nicht hochgradig spannend, aber solange wir uns noch nicht eingehender mit Licht und Shading beschäftigt haben, können wir auch nicht mehr erwarten - und wir haben beim Raytracing ja leider das Problem, daß wir ganz von vorne anfangen müssen:

<cpp>public RaytraceImage ( int width , int height )
{
// near und far sind die Werte fuer den Bereich ,
// von dem Tiefeninformationen abgebildet werden
for ( int x = 0; x < width; x++) {
for ( int y = 0 ; y < height; y++) {
Ray shoot = ShootRay (x , y);
double maxdist = double.Infinity;

foreach (Kugel obj in SichtbareKugeln) {
double hitdist = obj.RayIntersect(shoot) ;
if (hitdist > 0 && maxdist > hitdist)
maxdist = hitdist;
}

if (maxdist < double.Infinity) {
SetColor(x, y, Colors.Gray (Math.Min(Math .Max(0,
(maxdist - near) / ( near - far ))), 1.0)) ;
}
else
SetColor(x, y, BackgroundColor);
}
}
}</cpp>
Eine kleine Anmerkung noch: Da wir uns noch nicht über Transformationen Gedanken gemacht haben, und unsere Kugeln bislang am Nullpunkt aufgehäng sind, können wir diese noch nicht positionieren - sprich es wird höchstens die größte Kugel sichtbar, weil alle weiteren verdeckt sind. Das lässt sich beheben, indem man vor dem Test auf Schnitt vom Ursprung des entsprechenden Strahles, die Position der Kugel abzieht.

== Ebenen ==
Mit Kugeln kann man zwar so einiges darstellen, aber nur Kugeln sind vielleicht doch etwas langweilig. Wir wollen deshalb noch Ebenen implementieren. Am besten betrachten wir diese dazu in der Normalform, d.h. die Ebene wird allein durch ihre Flächennormale angegeben. Für Punkte auf der Ebene gilt dann:
[[Bild:Tutorial_RaytracingI_ebenengleichung.png|center]]
Setzt man nun in x unseren Strahl ein, ergibt sich:
[[Bild:Tutorial_RaytracingI_ebenenrechnung.png|center]]
Ist <d,n>=0, dann gibt es keine Lösung, sonst genau eine.

Welche Objekte eignen sich sonst gut zum Raytracing? ... Alle Objekte, die sich in kartesischen Koordinaten durch eine Gleichung der Form [[Bild:Tutorial_RaytracingI_kartesisch.png|center]] darstellen lassen. In (x,y,z) setzt man seinen Strahl r(t) ein und versucht nach t aufzulösen. In einigen Fällen wird dieses Problem leider kaum zu lösen sein: man kommt dann um den Einsatz von numerischen Verfahren nicht herum. Ich werde versuchen, in Folgetutorials noch ein paar weitere, interessante Objekte vorzustellen, die sich direkt lösen lassen und wenn ich viel Geduld habe, vielleicht auch einmal einen eigenen Artikel bezüglich numerischer Verfahren.

== Vorschau ==
Damit sind wir auch schon wieder soweit. Die ersten Grundlagen sind abgehandelt, aber wirklich überzeugt sind wir vom Raytracing noch nicht. Damit sich das ändert, sind weitere Tutorials in Planung: Wir wollen uns dann mit Licht und Normalen beschäftigen. Ausserdem sind Reflektionen und Transparenz spannende Dinge, denen wir uns widmen können. Wir wollen ausserdem unsere Objekte transformieren, scheeren, rotieren, ... Es bleibt also noch einiges im Bereich Raytracing zu tun, was hier nicht behandelt wurde.

Bis es soweit ist, könnt ihr euch ja selbst schonmal ein paar Gedanken zum Thema machen oder euch doch lieber in die Weiten von OpenGl flüchten.

'''[[Benutzer:Nico Michaelis|Nico Michaelis]]'''

Benutzer:Luketheduke

2006-05-30T13:25:55Z

Luketheduke:

ist das meine eigene Seite? Zum Blödsinn schreiben über mich und meine Haustiere?

Wenn ja:

Ich bin 16 Jahre alt, gehe auf die 10. Klasse Gamnasium, häng den ganzen Tag am Computer(America's Army, Delphi, PHP).

Ansonsten beschäftige ich mich mit Robotik, Elektronik oder lese Bücher.

Hier im Wiki mach ich vor allem Rechtschreib-Korrekturen.

--[[Benutzer:Luketheduke|luketheduke]] 15:25, 30. Mai 2006 (CEST)

Diskussion:DelphiGL

2006-05-30T13:19:19Z

Luketheduke:

==Geschichte==

So wie's aussieht gab's hier wohl keine "frühsten Anfänge" ;-) Die DGL war auf einmal da :P

Ne, wäre echt schön, wenn hier einmal eine kleine Geschichtsbeschreibung ähnlich der für [[omwiki:Projektgeschichte|Projektgeschichte für Omorphia (ext)]] zu finden wäre.

Ich kann leider zu diesem Beitrag nichts selber beisteuern, da ich erst wesentlich später zur DGLC gekommen bin.

MfG, --[[Benutzer:BenBE|BenBE]] 21:05, 14. Dez 2005 (CET)

Das gibts ja jetzt ;)
Hab mir auch erlaubt, in dem Text von Phobeus ein paar Sachen, die mir fehlerhaft erschienen, zu ändern bzw. auszubessern.
Hab außerdem hier mal die Diskussionsseite bisschen formatiert.
--[[Benutzer:Luketheduke|luketheduke]] 15:19, 30. Mai 2006 (CEST)

==Mitgliederentwicklung==
Hallo, bei der Bildunterschrift zum Diagramm "Mitgliederentwicklung" kann ich mit den Zahlen "18.09", "21.83" und "25.83" kaum was anfangen. Trennpunkte müssten ja wohl beim Tausender-Schritt stehen ("1.809"), und Dezimalstellen kommen mir 1. unwahrscheinlich vor und 2. im Deutschen bitte ein Komma. Oder zumindest einen Hinweis.

--[[Benutzer:Luketheduke|luketheduke]] 12:11, 2. Apr 2006 (CEST)

DelphiGL

2006-05-30T13:16:37Z

Luketheduke: /* Kleine orthografische Modifikationen ;) */

{|
|Dieser Artikel beschäftigt sich mit [http://DelphiGL.com DelphiGL.com]. 
DelphiGL ist die Website welche dieses Wiki betreibt und das angeschlossene Forum ist der feste Hafen für deutschsprachige OpenGL-Programmierer im sturmumtosten GrafikAPI-Ozean.
|<div align="right">[http://delphiGL.com http://delphigl.com/gfx/banner/banner256x64.gif]</div>
|-
|}

==Mitgliederentwicklung==
[[Bild:DGL_Mitgliederzahlen.jpg|center|framed|
Monatliches Wachstum der DGL Community: 
- insgesamt: 18.36 Mitglieder. 
- letzten 12 Monate: 23.08 Mitglieder. 
- letzten 6 Monate: 26.33 Mitglieder.]]

Für Liebhaber von Statistiken:
<div align="center">
{|{{Prettytable_B1}}
|+Halbjährliche Mitgliederentwicklung
!Zeitraum
!durchschnittlicher Zuwachs
|-
|01.06.02 - 01.11.02
|13
|-
|01.12.02 - 01.05.03
|13.5
|-
|01.06.03 - 01.11.03
|17.66
|-
|01.12.03 - 01.05.04
|16
|-
|01.06.04 - 01.11.04
|18
|-
|01.12.04 - 01.05.05
|19.5
|-
|01.06.05 - 01.11.05
|19.83
|-
|01.12.05 - 01.05.06
|27
|-
|}
</div>

==Geschichte von DelphiGL.com==
===Die frühsten Anfänge===
Blickt man insbesondere vor das Jahr 2000 war die Grafikprogrammierung unter Delphi eine ziemlich frustrierende Angelegenheit. Nur sehr wenige Quellen waren überhaupt verfügbar, ganz zu schweigen von notwendigen Headern. Ein erste Etappe dieser Durststrecke war vermutlich das Erscheinen von DelphiX, dass sich binnen kurzer Zeit einer sehr großen Popularität erfreute. Der gemeinsame Treffpunkt hierfür war das alte Forum auf www.neobrothers.de. Prinzipiell machte die Community bis zu diesem Zeitpunkt nichts anderes als langsam zu wachsen und alle Varianten der Grafikprogrammierung durchzugehen. Vermutlich gab es damals kaum jemanden der nicht DelphiX, WdirectX oder diverse andere Header durchprobierte.

Anfang 2002 kam es dann im Neobrothers-Forum zu einer Umfrage, ob man nicht ein Unterforum für OpenGL einrichten sollte. Zu diesem Zeitpunkt war mir (Phobeus) der Begriff OpenGL noch kaum ein Begriff. Da ich zu diesem Zeitpunkt jedoch zunehmend unzufriedener mit Direct3D wurde (Ständige Wechsel der API, zuviel Code für zu wenig Ergebnis etc.) riskierte ich einen Blick auf OpenGL und begann, mich damit auseinander zu setzen. Die Seite erster Wahl war damals für den OpenGL-Programmierer definitiv NeHe und erlaubte es mir mich relativ schnell in OpenGL einzuarbeiten. Das Ergebnis beeindruckte mich: Wenige Wochen und man konnte fast das gleiche machen wie mit Direct3D, allerdings oftmals mit erheblich weniger Code und alleine die Tatsache, dass man mit ein paar glVertex-Aufrufen schnell Figuren bilden konnte, beeindruckte mich sehr.

Zeitgleich nahm die Umfrage im Neobrothers-Forum ein Ende und mit nur wenigen Stimmen Vorsprung siegte die Direct3D-Fraktion und es wurde abgelehnt ein entsprechendes Unterforum einzurichten. Ich selbst war zu diesem Zeitpunkt über das Ergebnis ziemlich enttäuscht. Ebenso ein weiteres Mitglied aus dem Forum namens Sebo, den man streng genommen als geistigen Vater von DGL nennen muss.

Ich selbst besaß damals ausreichend Webspace und unterhielt dort eine kleine Seite für einige Projekte meinerseits. Er fragte mich, ob man nicht dort dann ein Unterforum einrichten könnte. Ich selbst war ziemlich skeptisch darüber, da ich nicht glaubte, dass ein kleines Unterforum in meinem „Gästebuch“ wirklich Interessierte anlocken könnte. Ich wollte Nägel mit Köpfen machen und es wurde mir hier erstmals bewußt, dass ich unlängst OpenGL als meine künftige API gewählt habe und definitiv nicht mehr zu Direct3D zurück wollte. Nach einer kurzen Sammlung von Ideen, Plänen und dem Entschluss auch Tutorials anbieten zu wollen, ging am 1. April 2002 die Webseite http://dgl.thechaoscompany.net/ (nicht mehr im Besitz) ans Netz. Inhalt war eine kleinere rote Webseite (http://www.phobeus.de/hosting/olddgl/) mit einem Forum auf einem Lycos-Account. Das Projekt wurde DGL genannt (ist jemand schon aufgefallen wie unsinnig der Name ist? Deutsche/Delphi Gomputer/Graphic Libary/Community? *sg) und wurde allgemein mit einem herzhaften Lachen aufgenommen. Die Tatsache, dass ein Direct3D-Programmierer plante, mit einer neuen OpenGL-Seite am ersten April ans Netz zu gehen, schien etwas belustigendes zu haben.

Was man über die Grafik-Community von Delphi im Jahre 2002 wissen sollte ist, dass Neobrothers.de ein zentrales Forum war in dem sich die Leute zum Sprechen trafen. Die Projekte selbst waren jedoch meist dezentral und jeder Entwickler / jedes Team werkelte im Stillen an seiner Arbeit herum. In der Tat beobachtete ich damals, dass viele Leute mehr Arbeit in Ihre Webseiten steckten als in die eigentliche Programmierung. DGL sollte anderes sein und ein wirkliches Portal sein. Warum muss jeder eine Webseite haben, die nur spärlich verlinkt ist, wenn es doch einen zentralen Ort geben kann an dem man das Wissen einfach zusammenträgt?

Bereits Ende April hatte DGL rund 20 Besucher täglich und lag damit weit über dem, was wir anfangs geschätzt hatten. Die Folge davon war, dass das Forum auf Grund des „hohen“ Traffic oftmals abends bereits gar nicht mehr erreichbar war. PHP-Webspace war damals noch recht teuer. Also kam es u.a. dazu, dass das Forum von DGL zwischenzeitlich bei Untergrund-Spiele (dem alten unter Krawall-Hosting), quellcodes.de und einem Cobal-Server lag. Ganz vereinzelt findet man noch in sehr alten Dateien unsere alte URL: http://dgl.quellcodes.de/. Keine dieser Seiten existiert heute noch so.

Bereits im Mai 2002 bekam ich eine ziemlich ernüchternde Mail von einem Entwickler, der mir bis dahin in der Szene nicht bekannt war: Lithander. Er ließ sich über das schreckliche Design der roten Seite auf und das man da doch sicherlich etwas besser machen könnte. Tja... dauerte keinen Tag, da hatte er einen neuen Job und es entstand das Design von DGL, das bis heute auf dem Server liegt – wenngleich die Technik dahinter mehrfach überarbeitet wurde. Kurze Zeit darauf erhielt ich eine E-Mail von Nico, der mir anbot ein Tutorial über Landschafts-Rendering zu schreiben. Kaum zu glauben, aber ich habe damals (auf Grund bisheriger Erfahrungen) das ganze für einen schlechten Scherz gehalten und bin umso mehr überrascht gewesen als plötzlich wirklich ein Tutorial bei mir im Postfach lag. Bereits zu dieser Zeit war Sebo nicht mehr wirklich für DGL aktiv (deswegen findet man auch kaum etwas von ihm), allerdings wurden Lithander und Nico ins Team aufgenommen.

Von da an wuchs DGL mit einer ziemlichen Geschwindigkeit. Ich selbst kann nur darüber schmunzeln, dass wir einst mit 10 MB Traffic am Tag Probleme hatten, ein Jahr später wurde bereits die 1,5 GB-Grenze gesprengt. Inzwischen kommt das gesamte DGL-Netz auf knapp 20 GB Traffic. Oftmals blicke ich mit einer Träne im Auge zurück auf das alte DGL, das sehr familiär gewesen ist – bei dem sich die Mitglieder fast alle mehr oder minder noch persönlich kannten. Dies ist inzwischen wohl kaum mehr möglich und der logistische Aufwand für die Community ist erheblich gestiegen. Dennoch ist es schön zu sehen, dass auch noch bei einer solch großen Seite sehr viele Leute da sind, die ebenso wie zur Gründungszeit bereit sind etwas für die Community beizutragen.

DGL ist eine Community die aus einer Laune heraus entstanden ist, als April-Scherz abgetan wurde und dennoch etwas sinnvolles wurde ;)

===Aprilscherze===
DGL selbst wurde ursprünglich selbst als Aprilscherz angesehen. Mittlerweile weiß man, dass es mehr wahr als ein Scherz.
Die Aprilscherze behalten aber ihren Stellenwert in der Community. Zwischen 0.00 und 1.00 Uhr erscheint an jedem 1. April ein erschreckender Newsbeitrag von Phobeus, der den Untergang des Abendlandes, zumindest aber sämtlicher Menschenrechte prophezeit bzw. als bereits vollzogen darstellt. Die News wird immer mit vielen Links zu echten Ereignissen und Schlagwörtern wie "CIA", "NSA", "EU-Kommission", aber immer auch mit Bezug auf die OpenGL-Entwicklung ("GL_ARB_QAIDA") gewürzt, so dass es einem zuerst beim Lesen, und dann nach der Auflösung und Präsentation der erschreckend harten Fakten kalt den Rücken herunterläuft.

====Bisherige April-News====

1. April 2006: [http://www.delphigl.com/forum/viewtopic.php?t=5398 Sicherheitsrichtlinie im Schnellverfahren]
:Die NSA platziert Backdoors in fast allen Systemen, darunter die OpenGL-Extension "GL_ARB_QAIDA" - alle persönlichen Daten sollen im Klartext zu entsprechenden Stellen weitergeleitet werden...

1. April 2005: [http://www.delphigl.com/forum/viewtopic.php?t=3993 Ein schwarzer Tag...]
:Softwarepatente machen fast alle Internetangebote von Open-Source-Gruppen illegal. Erste Homepages gehen bereits vom Netz.

===Die Community aktuell===
Seit Mitte 2005 kam neben '''OpenGL''' vor allem '''SDL''' als Thema in der DGL Community auf. Plattformunabhängige Programmierung wurde dadurch zunehmend häufiger ein Ziel der DGLer, was im Start der Übersetzung der [[SDL-Funktionsübersicht|SDL-Dokumentation im DGL-Wiki]] gipfelte.

Des weiteren entwickelte sich DGL von einer "Randgruppen-Randgruppe" (Zitat: Phobeus) hin zu einem OpenGL-Forum, unabhängig welcher Sprache man den Vorzug gibt. Zwar sind die '''Delphi'''- bzw. '''FPC'''-Programmierer immer noch in der Überzahl, aber auch '''C++'''ler, '''C#'''- und '''Java'''-Programmierer sieht man häufiger.

Neben diesen Veränderungen befassten sich einige Mitglieder über längere Zeit hinweg mit '''.Net''' und den Chancen die dieser neue Weg mit sich bringt. Da .Net vorallem in Linuxkreisen recht umstritten ist kam es zwangsläufig immer wieder zu recht kontroversen Diskussionen. Trotz alledem trug diese Bewegung dazu bei dass DGL auch weiterhin Fragen aus einem breiten Spektrum beantworten kann.

DGL ist aber nicht nur als Forum aktiv. Zur Zeit bestreitet DelphiGL.com 3 Großprojekte:
*[http://quake3.delphigl.com/index.php/Main_Page '''Quake3Delphi''']
:Das wohl '''spektakulärste Projekt''' der DGL ist die Portierung des öffentlichen Quake3 Codes von C++ nach Delphi. Dieses Projekt stellt den Nachfolger des [http://quake2delphi.sourceforge.net/ Quake2Delphi]-Projektes dar.

*'''[[Hauptseite|DGL-Wiki]]'''
:Das DGL-Wiki ist das wohl '''nützlichste Projekt''' der DGL, denn es bündelt das Wissen vieler OpenGLer und stellt es in deutscher Sprache Interessierten zur Verfügung. Neben diesem altruistischen Effekt hilft das Wiki auch, die Wartbarkeit zu erhöhen. Folge dessen ist, dass Fehler, die von unseren Mitgliedern gefunden werden, sofort berichtigt werden können. (Sie befinden sich gerade im DGL-Wiki ;-))

:Im DGL-Wiki findet man [[OpenGL-Funktionsübersicht|OpenGL Funktionen]], [[Hintergrundwissen]] und [[Link]]s und vieles vieles mehr.

*'''[[DGLSDK]]'''
:Der DGLSDK ist das '''hilfreichste Projekt''' der DGL-Comunity. Bereits 2003 war eine erste Version verfügbar, entwickelte sich aber nicht wie erhofft. Seit 2005 ist nun eine verbesserte und ständig aktualisierte Version verfügbar, die Einsteigern in die OpenGL-Programmierung mit Delphi bzw. FPC alle nötigen Werkzeuge nicht nur an die Hand gibt, sondern auch gleich noch einrichtet.

Was herauskommen kann, wenn die Mitglieder von DelphiGL.com in die Tasten hauen, kann in der [[DGL Projekte|'''DGL Projekteecke''']] betrachtet werden.

===Historie im Überblick===
Die nachfolgende Tabelle versucht, aus den Newsmeldungen die im Forum von DelphiGL.com zu finden sind, zumindest ausschnittsweise die Geschichte von DelphiGL.com zu rekonstruieren.

[[Bild:DGL_Map.jpg|right|framed|Die [http://www.frappr.com/delphigl Original DGL-Map] gibt euch einen Überblick, wo die DGL-Mitglieder wohnen.]]

<div align="center">
{|{{Prettytable_B1}}
!Datum||Mitglieder bis ''Datum''||Veränderungen/Ereignisse bis ''Datum''
|- align = "center"
|01.06.2002||13||
|- align = "center"
|01.07.2002||22||erste OpenGL <-> Direct3D Schlammschlacht
|- align = "center"
|01.08.2002||31||Member Forum 
Erste Idee Page ins englische zu übersetzen (per McClaw)
|- align = "center"
|01.09.2002||42||Erster Umzug von DGL 
Spruch des Tages
|- align = "center"
|01.10.2002||58||SchodMC wird Mod 
DGL-Upload-Center 
Poll 
Recent Uploads 
Featured Sites 
Bild der Woche 
Snippets
|- align = "center"
|01.11.2002||78||TexturenTutorial 
Foren FAQ
 Poll Archiv
|- align = "center"
|01.12.2002||87||DelphiGL.com Domain 
Kommentare zu Newsmeldungen
|- align = "center"
|01.01.2003||106||Neues DGL Logo 
'''''100 Mitglieder-Marke erreicht'''''
|- align = "center"
|01.02.2003||123||Umzug auf neuen Server 
Sascha Willems (SonOfSatan / SOS) wird Mod 
Tutorials als CHM-Version
|- align = "center"
|01.03.2003||136||
|- align = "center"
|01.04.2003||147||Bomberman Tutorial 2
|- align = "center"
|01.05.2003||159||Projekteforum eingerichtet
 Phobeus stellt Firefox vor (damals Firebird)
|- align = "center"
|01.06.2003||175||
|- align = "center"
|01.07.2003||196||
|- align = "center"
|01.08.2003||212||IE erkennt DGL als nicht vertrauensvoll ;-) 
Flooding durch MS-Bots
|- align = "center"
|01.09.2003||223||Ausfall der Domain
|- align = "center"
|01.10.2003||245||
|- align = "center"
|01.11.2003||265||
|- align = "center"
|01.12.2003||277||Erster IRC-Chat
|- align = "center"
|01.01.2004||296||
|- align = "center"
|01.02.2004||308||
|- align = "center"
|01.03.2004||323||
|- align = "center"
|01.04.2004||347||Borland Developer Network und
Code Central News 
W32.Beagle.J@MM Wurm nimmt DGL-Identität an.
|- align = "center"
|01.05.2004||361||
|- align = "center"
|01.06.2004||378||dglOpenGL.pas - Version 1.4
|- align = "center"
|01.07.2004||403||'''DGL Wiki gestartet'''
|- align = "center"
|01.08.2004||421||Atom Feed
|- align = "center"
|01.09.2004||438||dglOpenGL.pas - Version 1.4B '''DGL Wiki hat 100 Artikel'''
|- align = "center"
|01.10.2004||451||dglOpenGL.pas goes FreePascal
|- align = "center"
|01.11.2004||469||
|- align = "center"
|01.12.2004||493||.Net Forum
|- align = "center"
|01.01.2005||512||dglOpenGL.pas - Version 1.6 
'''''500 Mitglieder-Marke erreicht'''''
|- align = "center"
|01.02.2005||531||dglOpenGL.pas - Version 1.7 '''DGL Wiki hat 250 Artikel'''
|- align = "center"
|01.03.2005||552||
|- align = "center"
|01.04.2005||570||
|- align = "center"
|01.05.2005||586||
|- align = "center"
|01.06.2005||604||
|- align = "center"
|01.07.2005||617||DGLSDK 2005.1
|- align = "center"
|01.08.2005||635||
|- align = "center"
|01.09.2005||661||Quake3Delphi
|- align = "center"
|01.10.2005||677||Diskussion zum Thema "Windows Vista & OpenGL"
|- align = "center"
|01.11.2005||705||
|- align = "center"
|01.12.2005||729|| '''DGL Wiki hat 500 Artikel'''
|- align = "center"
|01.01.2006||767|| '''DGL Wiki Phasen 1 u. 2 abgeschlossen''' Weihnachtsaktion: Portierung der DGL-Tutorials ins Wiki DGL-Mitglieder starten DGL-Map bei "Frappr.com"
|- align = "center"
|01.02.2006||797||
|- align = "center"
|01.03.2006||832|| Borland will sich von seiner IDE-Sparte trennen
|- align = "center"
|01.04.2006||863|| Windows Vista soll nun doch OpenGL voll unterstützen
|- align = "center"
|01.05.2006||891|| SGI beantragt Gläubigerschutz
|}
</div>

==Links==
[http://www.delphiGL.com http://www.DelphiGL.com - Heimat der DGLer]

[http://www.frappr.com/delphigl Link zur DGL_Map]

[http://quake3.delphigl.com/index.php/Main_Page DGL-Projekt 'Quake3Delphi']

[[DGL Projekte|Link auf die DGL Projekteecke]]

Diskussion:ZFighting

2006-05-30T13:02:14Z

Luketheduke:

Der Link ganz unten ist kaputt... --[[Benutzer:Luketheduke|luketheduke]] 15:02, 30. Mai 2006 (CEST)

glTexEnv

2006-04-07T14:28:22Z

Luketheduke: /* Beschreibung */

{{Unvollständig}}
= glTexEnv =

 
== Name ==
'''glTexEnvf''', '''glTexEnvi''', '''glTexEnvfv''', '''glTexEnviv''' - Setzt Parameter für das Textur-Environment
 
== Delphi-Spezifikation ==
procedure '''glTexEnvf'''(''target'' : GLenum; ''pname'' : GLenum; ''param'' : GLfloat) 
procedure '''glTexEnvi'''(''target'' : GLenum; ''pname'' : GLenum; ''param'' : GLint)

 

== Parameter ==

{| border="1" rules="all"
! ''target''
| Gibt ein Textur-Environment an. Muss vom Typ '''GL_TEXTURE_ENV''' sein.
|-
! ''pname''
| Gibt den symbolischen Namen eines Parameters des Textur-Environments an. Muss vom Typ '''GL_TEXTURE_ENV_MODE''' sein.
|-
! ''param''
| Gibt eine einzelne symbolische Konstante an. Muss entweder vom Typ '''GL_MODULATE''', '''GL_DECAL''', '''GL_BLEND''' oder '''GL_REPLACE'''.
|}

 

== Delphi-Spezifikation ==
procedure '''glTexEnvfv'''(''target'' : GLenum; ''pname'' : GLenum; '''const''' ''params'' : ^GLfloat) 
procedure '''glTexEnviv'''(''target'' : GLenum; ''pname'' : GLenum; '''const''' ''params'' : ^GLint)

 

== Parameter ==

{| border="1" rules="all"
! ''target''
| Gibt ein Textur-Environment an. Muss vom Typ '''GL_TEXTURE_ENV''' sein.
|-
! ''pname''
| Gibt den symbolischen Namen eines Parameters des Textur-Environments an. Akzeptiert werden '''GL_TEXTURE_ENV_MODE''' und '''GL_TEXTURE_ENV_COLOR'''.
|-
! ''params''
| Gibt einen Pointer auf ein Parameter-Array an, das entweder eine einzelne symbolische Konstante oder eine Farbe im RGBA-Format enthält.
|}

 

== Beschreibung ==
Ein Textur-Environment legt fest, wie Texturwerte interpretiert werden, wenn ein Fragment texturiert wird. ''target'' muss vom Typ '''GL_TEXTURE_ENV''' sein. ''pname'' kann '''GL_TEXTURE_ENV_MODE''' oder '''GL_TEXTURE_ENV_COLOR''' sein. 
 
Wenn ''pname'' die Konstante '''GL_TEXTURE_ENV_MODE zugewiesen ist, dann ist ''params'' (bzw zeigt ''params'' auf) der symbolische Name einer Texturfunktion. Vier Texturfunktionen müssen angegeben werden: '''GL_MODULATE''', '''GL_DECAL''', '''GL_BLEND''' und '''GL_REPLACE'''. 
 
Eine Texturfunktion wird unter Verwendung des Textur-Wertes des zu behandelnden Fragments auf das zu texturierende Fragment angewendet (siehe [[glTexParameter]]) und erzeugt eine Farbe im RGBA-Format für dieses Fragment. Die folgende Tabelle zeigt, wie die RGBA-Farbe durch jede dieser wählbaren Funktionen generiert wird. C ist ein Triplet mit den Farbwerten (R,G,B) und A ist der Alpha-Wert. RGBA-Werte, die aus der Textur entnommen werden, sind in dem Bereich [0,1]. Das tiefergestellte f bezieht sich auf eingehende Fragment, das tiefergestellte c auf die Farbe des Textur-Environments und das tiefergestellte v verweist auf der Wert, den die Texturfunktion liefert. 
 
Eine Textur kann bis zu vier Komponenten pro Texturelement haben (siehe '''glTexImage1D''', '''glTexImage2D''', '''glCopyTexImage1D''' und '''glCopyTexImage2D'''). In einem Bild mit einer Komponente, zeigt L auf diese einzelne Komponente. Ein Bild mit zwei Komponenten nutzt L und A. Ein Bild mit drei Komponenten hat nur einen Color-Wert Ct. Ein Bild mit vier Komponenten hat einen Farbwert C und einen Alpha-Wert A. 
 
 

{| {{Prettytable_B1}}
! rowspan="2" | Base internal format
|-
| GL_MODULATE
| GL_DECAL
| GL_BLEND
| GL_REPLACE
|-
! GL_ALPHA
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| undefined
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_t.png]]
|-
! GL_LUMINANCE 1
| [[Bild:C_v_ist_L_t_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| undefined
| [[Bild:C_v_ist_(1-L_t)C_f-L_t_C_c.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_L_t.png]] [[Bild:A_v_ist_A_f.png]]
|-
! GL_LUMINANCE_ALPHA 2
| [[Bild:C_v_ist_L_t_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| undefined
| [[Bild:C_v_ist_(1-L_t)C_f-L_t_C_c.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_L_t.png]] [[Bild:A_v_ist_A_t.png]]
|-
! GL_INTENSITY
| [[Bild:C_v_ist_C_f_I_t.png]] [[Bild:A_v_ist_A_f_I_t.png]]
| undefined
| [[Bild:C_v_ist_(1-I_t)C_f-I_t_C_c.png]] [[Bild:A_V_ist_(1-I_t)A_f-I_t_A_c.png]]
| [[Bild:C_v_ist_I_t.png]] [[Bild:A_v_ist_I_t.png]]
|-
! GL_RGB 3
| [[Bild:C_v_ist_C_t_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_t.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_(1-C_t)C_f-C_t_C_c.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_t.png]] [[Bild:A_v_ist_A_f.png]]
|-
! GL_RGBA 4
| [[Bild:C_v_ist_C_t_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_(1-A_t)C_f-A_t_C_t.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_(1-C_t)C_f-C_t_C_c.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_C_t.png]]
|}

 
Wenn ''pname'' vom Typ '''GL_TEXTURE_ENV_COLOR''' ist, ist '''params''' ein Pointer auf ein Array, das eine Farbe im RGBA-Format enhält. Farbkomponenten aus Integer-Werten werden linear interpretiert, so dass der größte positive Integer-Wert auf 1.0 und der kleinste negative Wert auf -1.0 fällt. Die Werte werden in den [0,1]-Bereich eingepasst, wenn sie spezifizert werden. Cc enthält diese vier Werte.

Werden keine Werte zugewiesen, dann hat '''GL_TEXTURE_ENV_MODE''' den Wert '''GL_MODULATE''' und '''GL_TEXTRE_ENV_COLOR''' die Werte (0, 0, 0, 0).

 

== Hinweise ==
'''GL_REPLACE''' ist nur verfügbar, wenn die OpenGL-Version gleich oder höher als 1.1 ist. 
 
Interne Formate anders als 1, 2, 3 oder 4 dürften nur nutzbar sein, wenn die OpenGL-Version gleich oder höher als 1.1 ist.
 

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:
=== Ab OpenGL Version 1.2.1 ===
Wenn mehrere [[Texture Stage]]s durch [[GL_ARB_multitexturing]] verwendet werden, so kann für jede [[Texture Stage]] die TexEnv-Funktion extra angegeben werden.

=== Ab OpenGL Version 1.3 ===
Wenn glTexEnvi( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB) verwendet wird, so wird die Berechnung der entsprechenden [[Texture Stage]] durch [[GL_ARB_texture_env_combine]] ersetzt.
 

== Fehlermeldungen ==
'''GL_INVALID_ENUM''' wird generiert, wenn ''target'' oder ''pname'' keine der akzeptablen, definierten Werte ist, oder wenn ''params'' eine definierte Konstante haben soll (abhängig vom Wert von ''pname'') und keine hat. 

'''GL_INVALID_OPERATION''' wird generiert, wenn glTexEnv innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

 

== Zugehörige Wertrückgaben ==
[[glGetTexEnv]]

 

== Siehe auch ==
[[glCopyPixels]], [[glCopyTexImage1D]], [[glCopyTexImage2D]], [[glCopyTexSubImage1D]], [[glCopyTexSubImage2D]], [[glTexImage1D]], [[glTexImage2D]], [[glTexParameter]], [[glTexSubImage1D]], [[glTexSubImage2D]]

 
[[Kategorie:GL|TexEnv]]

glTexEnv

2006-04-07T14:27:05Z

Luketheduke: offline-kategorisierung entfernt

{{Unvollständig}}
= glTexEnv =

 
== Name ==
'''glTexEnvf''', '''glTexEnvi''', '''glTexEnvfv''', '''glTexEnviv''' - Setzt Parameter für das Textur-Environment
 
== Delphi-Spezifikation ==
procedure '''glTexEnvf'''(''target'' : GLenum; ''pname'' : GLenum; ''param'' : GLfloat) 
procedure '''glTexEnvi'''(''target'' : GLenum; ''pname'' : GLenum; ''param'' : GLint)

 

== Parameter ==

{| border="1" rules="all"
! ''target''
| Gibt ein Textur-Environment an. Muss vom Typ '''GL_TEXTURE_ENV''' sein.
|-
! ''pname''
| Gibt den symbolischen Namen eines Parameters des Textur-Environments an. Muss vom Typ '''GL_TEXTURE_ENV_MODE''' sein.
|-
! ''param''
| Gibt eine einzelne symbolische Konstante an. Muss entweder vom Typ '''GL_MODULATE''', '''GL_DECAL''', '''GL_BLEND''' oder '''GL_REPLACE'''.
|}

 

== Delphi-Spezifikation ==
procedure '''glTexEnvfv'''(''target'' : GLenum; ''pname'' : GLenum; '''const''' ''params'' : ^GLfloat) 
procedure '''glTexEnviv'''(''target'' : GLenum; ''pname'' : GLenum; '''const''' ''params'' : ^GLint)

 

== Parameter ==

{| border="1" rules="all"
! ''target''
| Gibt ein Textur-Environment an. Muss vom Typ '''GL_TEXTURE_ENV''' sein.
|-
! ''pname''
| Gibt den symbolischen Namen eines Parameters des Textur-Environments an. Akzeptiert werden '''GL_TEXTURE_ENV_MODE''' und '''GL_TEXTURE_ENV_COLOR'''.
|-
! ''params''
| Gibt einen Pointer auf ein Parameter-Array an, das entweder eine einzelne symbolische Konstante oder eine Farbe im RGBA-Format enthält.
|}

 

== Beschreibung ==
Ein Textur-Environment legt fest, wie Texturwerte interpretiert werden, wenn ein Fragment texturiert wird. ''target'' muss vom Typ '''GL_TEXTURE_ENV''' sein. ''pname'' kann '''GL_TEXTURE_ENV_MODE''' oder '''GL_TEXTURE_ENV_COLOR''' sein. 
 
Wenn ''pname'' die Konstante '''GL_TEXTURE_ENV_MODE zugewiesen ist, dann ist ''params'' (bzw zeigt ''params'' auf) der symbolische Name einer Texturfunktion. Vier Texturfunktionen müssen angegeben werden: '''GL_MODULATE''', '''GL_DECAL''', '''GL_BLEND''' und '''GL_REPLACE'''. 
 
Eine Texturfunktion wird unter Verwendung des Textur-Wertes des zu behandelnden Fragments auf das zu texturierende Fragment angewendet (siehe [[glTexParameter]]) und erzeugt eine Farbe im RGBA-Format für dieses Fragment. Die folgende Tabelle zeigt, wie die RGBA-Farbe durch jede dieser wählbaren Funktionen generiert wird. C ist ein Triplet mit den Farbwerten (R,G,B) und A ist der Alpha-Wert. RGBA-Werte, die aus der Textur entnommen werden, sind in dem Bereich [0,1]. Das tiefergestellte f bezieht sich auf eingehende Fragment, das tiefergestellte c auf die Farbe des Textur-Environments und das tiefergestellte v verweist auf der Wert, den die Texturfunktion liefert. 
 
Eine Textur kann bis zu vier Komponenten pro Texturelement haben (siehe '''glTexImage1D''', '''glTexImage2D''', '''glCopyTexImage1D''' und '''glCopyTexImage2D'''). In einem Bild mit einer Komponente, zeigt L auf diese einzelne Komponente. Ein Bild mit zwei Komponenten nutzt L und A. Ein Bild mit drei Komponenten hat nur einen Color-Wert Ct. Ein Bild mit vier Komponenten hat einen Farbwert C und einen Alpha-Wert A. 
 
 

{| {{Prettytable_B1}}
! rowspan="2" | Base internal format
|-
| GL_MODULATE
| GL_DECAL
| GL_BLEND
| GL_REPLACE
|-
! GL_ALPHA
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| undefined
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_t.png]]
|-
! GL_LUMINANCE 1
| [[Bild:C_v_ist_L_t_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| undefined
| [[Bild:C_v_ist_(1-L_t)C_f-L_t_C_c.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_L_t.png]] [[Bild:A_v_ist_A_f.png]]
|-
! GL_LUMINANCE_ALPHA 2
| [[Bild:C_v_ist_L_t_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| undefined
| [[Bild:C_v_ist_(1-L_t)C_f-L_t_C_c.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_L_t.png]] [[Bild:A_v_ist_A_t.png]]
|-
! GL_INTENSITY
| [[Bild:C_v_ist_C_f_I_t.png]] [[Bild:A_v_ist_A_f_I_t.png]]
| undefined
| [[Bild:C_v_ist_(1-I_t)C_f-I_t_C_c.png]] [[Bild:A_V_ist_(1-I_t)A_f-I_t_A_c.png]]
| [[Bild:C_v_ist_I_t.png]] [[Bild:A_v_ist_I_t.png]]
|-
! GL_RGB 3
| [[Bild:C_v_ist_C_t_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_t.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_(1-C_t)C_f-C_t_C_c.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_t.png]] [[Bild:A_v_ist_A_f.png]]
|-
! GL_RGBA 4
| [[Bild:C_v_ist_C_t_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_(1-A_t)C_f+A_t_C_t.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_(1-C_t)C_f+C_t_C_c.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_C_t.png]]
|}

 
Wenn ''pname'' vom Typ '''GL_TEXTURE_ENV_COLOR''' ist, ist '''params''' ein Pointer auf ein Array, das eine Farbe im RGBA-Format enhält. Farbkomponenten aus Integer-Werten werden linear interpretiert, so dass der größte positive Integer-Wert auf 1.0 und der kleinste negative Wert auf -1.0 fällt. Die Werte werden in den [0,1]-Bereich eingepasst, wenn sie spezifizert werden. Cc enthält diese vier Werte.

Werden keine Werte zugewiesen, dann hat '''GL_TEXTURE_ENV_MODE''' den Wert '''GL_MODULATE''' und '''GL_TEXTRE_ENV_COLOR''' die Werte (0, 0, 0, 0).

 

== Hinweise ==
'''GL_REPLACE''' ist nur verfügbar, wenn die OpenGL-Version gleich oder höher als 1.1 ist. 
 
Interne Formate anders als 1, 2, 3 oder 4 dürften nur nutzbar sein, wenn die OpenGL-Version gleich oder höher als 1.1 ist.
 

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:
=== Ab OpenGL Version 1.2.1 ===
Wenn mehrere [[Texture Stage]]s durch [[GL_ARB_multitexturing]] verwendet werden, so kann für jede [[Texture Stage]] die TexEnv-Funktion extra angegeben werden.

=== Ab OpenGL Version 1.3 ===
Wenn glTexEnvi( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB) verwendet wird, so wird die Berechnung der entsprechenden [[Texture Stage]] durch [[GL_ARB_texture_env_combine]] ersetzt.
 

== Fehlermeldungen ==
'''GL_INVALID_ENUM''' wird generiert, wenn ''target'' oder ''pname'' keine der akzeptablen, definierten Werte ist, oder wenn ''params'' eine definierte Konstante haben soll (abhängig vom Wert von ''pname'') und keine hat. 

'''GL_INVALID_OPERATION''' wird generiert, wenn glTexEnv innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

 

== Zugehörige Wertrückgaben ==
[[glGetTexEnv]]

 

== Siehe auch ==
[[glCopyPixels]], [[glCopyTexImage1D]], [[glCopyTexImage2D]], [[glCopyTexSubImage1D]], [[glCopyTexSubImage2D]], [[glTexImage1D]], [[glTexImage2D]], [[glTexParameter]], [[glTexSubImage1D]], [[glTexSubImage2D]]

 
[[Kategorie:GL|TexEnv]]

glTexEnv

2006-04-07T14:25:06Z

Luketheduke: /* Tabelle bebildert */

{{Unvollständig}}
{{Offline}}
= glTexEnv =

 
== Name ==
'''glTexEnvf''', '''glTexEnvi''', '''glTexEnvfv''', '''glTexEnviv''' - Setzt Parameter für das Textur-Environment
 
== Delphi-Spezifikation ==
procedure '''glTexEnvf'''(''target'' : GLenum; ''pname'' : GLenum; ''param'' : GLfloat) 
procedure '''glTexEnvi'''(''target'' : GLenum; ''pname'' : GLenum; ''param'' : GLint)

 

== Parameter ==

{| border="1" rules="all"
! ''target''
| Gibt ein Textur-Environment an. Muss vom Typ '''GL_TEXTURE_ENV''' sein.
|-
! ''pname''
| Gibt den symbolischen Namen eines Parameters des Textur-Environments an. Muss vom Typ '''GL_TEXTURE_ENV_MODE''' sein.
|-
! ''param''
| Gibt eine einzelne symbolische Konstante an. Muss entweder vom Typ '''GL_MODULATE''', '''GL_DECAL''', '''GL_BLEND''' oder '''GL_REPLACE'''.
|}

 

== Delphi-Spezifikation ==
procedure '''glTexEnvfv'''(''target'' : GLenum; ''pname'' : GLenum; '''const''' ''params'' : ^GLfloat) 
procedure '''glTexEnviv'''(''target'' : GLenum; ''pname'' : GLenum; '''const''' ''params'' : ^GLint)

 

== Parameter ==

{| border="1" rules="all"
! ''target''
| Gibt ein Textur-Environment an. Muss vom Typ '''GL_TEXTURE_ENV''' sein.
|-
! ''pname''
| Gibt den symbolischen Namen eines Parameters des Textur-Environments an. Akzeptiert werden '''GL_TEXTURE_ENV_MODE''' und '''GL_TEXTURE_ENV_COLOR'''.
|-
! ''params''
| Gibt einen Pointer auf ein Parameter-Array an, das entweder eine einzelne symbolische Konstante oder eine Farbe im RGBA-Format enthält.
|}

 

== Beschreibung ==
Ein Textur-Environment legt fest, wie Texturwerte interpretiert werden, wenn ein Fragment texturiert wird. ''target'' muss vom Typ '''GL_TEXTURE_ENV''' sein. ''pname'' kann '''GL_TEXTURE_ENV_MODE''' oder '''GL_TEXTURE_ENV_COLOR''' sein. 
 
Wenn ''pname'' die Konstante '''GL_TEXTURE_ENV_MODE zugewiesen ist, dann ist ''params'' (bzw zeigt ''params'' auf) der symbolische Name einer Texturfunktion. Vier Texturfunktionen müssen angegeben werden: '''GL_MODULATE''', '''GL_DECAL''', '''GL_BLEND''' und '''GL_REPLACE'''. 
 
Eine Texturfunktion wird unter Verwendung des Textur-Wertes des zu behandelnden Fragments auf das zu texturierende Fragment angewendet (siehe [[glTexParameter]]) und erzeugt eine Farbe im RGBA-Format für dieses Fragment. Die folgende Tabelle zeigt, wie die RGBA-Farbe durch jede dieser wählbaren Funktionen generiert wird. C ist ein Triplet mit den Farbwerten (R,G,B) und A ist der Alpha-Wert. RGBA-Werte, die aus der Textur entnommen werden, sind in dem Bereich [0,1]. Das tiefergestellte f bezieht sich auf eingehende Fragment, das tiefergestellte c auf die Farbe des Textur-Environments und das tiefergestellte v verweist auf der Wert, den die Texturfunktion liefert. 
 
Eine Textur kann bis zu vier Komponenten pro Texturelement haben (siehe '''glTexImage1D''', '''glTexImage2D''', '''glCopyTexImage1D''' und '''glCopyTexImage2D'''). In einem Bild mit einer Komponente, zeigt L auf diese einzelne Komponente. Ein Bild mit zwei Komponenten nutzt L und A. Ein Bild mit drei Komponenten hat nur einen Color-Wert Ct. Ein Bild mit vier Komponenten hat einen Farbwert C und einen Alpha-Wert A. 
 
 

{| {{Prettytable_B1}}
! rowspan="2" | Base internal format
|-
| GL_MODULATE
| GL_DECAL
| GL_BLEND
| GL_REPLACE
|-
! GL_ALPHA
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| undefined
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_f.png]] [[Bild:A_v_ist_A_t.png]]
|-
! GL_LUMINANCE 1
| [[Bild:C_v_ist_L_t_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| undefined
| [[Bild:C_v_ist_(1-L_t)C_f-L_t_C_c.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_L_t.png]] [[Bild:A_v_ist_A_f.png]]
|-
! GL_LUMINANCE_ALPHA 2
| [[Bild:C_v_ist_L_t_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| undefined
| [[Bild:C_v_ist_(1-L_t)C_f-L_t_C_c.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_L_t.png]] [[Bild:A_v_ist_A_t.png]]
|-
! GL_INTENSITY
| [[Bild:C_v_ist_C_f_I_t.png]] [[Bild:A_v_ist_A_f_I_t.png]]
| undefined
| [[Bild:C_v_ist_(1-I_t)C_f-I_t_C_c.png]] [[Bild:A_V_ist_(1-I_t)A_f-I_t_A_c.png]]
| [[Bild:C_v_ist_I_t.png]] [[Bild:A_v_ist_I_t.png]]
|-
! GL_RGB 3
| [[Bild:C_v_ist_C_t_C_f.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_t.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_(1-C_t)C_f-C_t_C_c.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_C_t.png]] [[Bild:A_v_ist_A_f.png]]
|-
! GL_RGBA 4
| [[Bild:C_v_ist_C_t_C_f.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_(1-A_t)C_f+A_t_C_t.png]] [[Bild:A_v_ist_A_f.png]]
| [[Bild:C_v_ist_(1-C_t)C_f+C_t_C_c.png]] [[Bild:A_v_ist_A_f_A_t.png]]
| [[Bild:C_v_ist_C_t.png]]
|}

 
Wenn ''pname'' vom Typ '''GL_TEXTURE_ENV_COLOR''' ist, ist '''params''' ein Pointer auf ein Array, das eine Farbe im RGBA-Format enhält. Farbkomponenten aus Integer-Werten werden linear interpretiert, so dass der größte positive Integer-Wert auf 1.0 und der kleinste negative Wert auf -1.0 fällt. Die Werte werden in den [0,1]-Bereich eingepasst, wenn sie spezifizert werden. Cc enthält diese vier Werte.

Werden keine Werte zugewiesen, dann hat '''GL_TEXTURE_ENV_MODE''' den Wert '''GL_MODULATE''' und '''GL_TEXTRE_ENV_COLOR''' die Werte (0, 0, 0, 0).

 

== Hinweise ==
'''GL_REPLACE''' ist nur verfügbar, wenn die OpenGL-Version gleich oder höher als 1.1 ist. 
 
Interne Formate anders als 1, 2, 3 oder 4 dürften nur nutzbar sein, wenn die OpenGL-Version gleich oder höher als 1.1 ist.
 

== Änderungen ==
Folgende Erweiterungen hat die Funktion erfahren:
=== Ab OpenGL Version 1.2.1 ===
Wenn mehrere [[Texture Stage]]s durch [[GL_ARB_multitexturing]] verwendet werden, so kann für jede [[Texture Stage]] die TexEnv-Funktion extra angegeben werden.

=== Ab OpenGL Version 1.3 ===
Wenn glTexEnvi( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE_ARB) verwendet wird, so wird die Berechnung der entsprechenden [[Texture Stage]] durch [[GL_ARB_texture_env_combine]] ersetzt.
 

== Fehlermeldungen ==
'''GL_INVALID_ENUM''' wird generiert, wenn ''target'' oder ''pname'' keine der akzeptablen, definierten Werte ist, oder wenn ''params'' eine definierte Konstante haben soll (abhängig vom Wert von ''pname'') und keine hat. 

'''GL_INVALID_OPERATION''' wird generiert, wenn glTexEnv innerhalb eines [[glBegin]]-[[glEnd]] Blocks aufgerufen wird.

 

== Zugehörige Wertrückgaben ==
[[glGetTexEnv]]

 

== Siehe auch ==
[[glCopyPixels]], [[glCopyTexImage1D]], [[glCopyTexImage2D]], [[glCopyTexSubImage1D]], [[glCopyTexSubImage2D]], [[glTexImage1D]], [[glTexImage2D]], [[glTexParameter]], [[glTexSubImage1D]], [[glTexSubImage2D]]

 
[[Kategorie:GL|TexEnv]]

Datei:C v ist C f I t.png

2006-04-07T14:09:48Z

Luketheduke: Formel für glTexEnv-Artikel.

Formel für glTexEnv-Artikel.

Datei:C v ist (1-I t)C f-I t C c.png

2006-04-07T14:00:53Z

Luketheduke:

Datei:C v ist (1-L t)C f-L t C c.png

2006-04-07T14:00:24Z

Luketheduke:

Datei:A v ist (1-I t)A f-I t A c.png

2006-04-07T13:58:44Z

Luketheduke:

Datei:A v ist A f.png

2006-04-07T13:58:29Z

Luketheduke:

Datei:A v ist A t.png

2006-04-07T13:57:55Z

Luketheduke: Formel für den glTexEnv-Artikel

Formel für den glTexEnv-Artikel

Datei:C v ist L t.png

2006-04-07T13:37:24Z