https://wiki.delphigl.com/api.php?action=feedcontributions&feedformat=atom&user=WaranDGL Wiki - Benutzerbeiträge [de]2026-05-30T23:30:05ZBenutzerbeiträgeMediaWiki 1.27.4https://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=24109Tutorial ColorPicking Shader2009-08-08T16:45:01Z<p>Waran: Korrigierte Versionen der Dateien</p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bot bisher leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren. Für Einsteiger mit weniger großen Ambitionen empfiehlt sich aber vorerst eher die [[Tutorial ColorPicking|shaderlose Variante]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welche mit einfacheren Mitteln auskommt.<br />
<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den [http://home.arcor.de/m3ep/tut_colorpicking/tut_colorpicking_src.zip restlichen Code] analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts. Damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(y) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt<br />
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches<br />
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber<br />
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern<br />
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas<br />
absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die<br />
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich<br />
wieder beim Immediate Mode landen und hättet <i>trotz</i> Listen, die durch die<br />
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,<br />
nichts gewonnen.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern<br />
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken<br />
und ganz nebenbei die caching performance des Treibers zu erhöhen. <br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (siehe unten) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
== Dateien ==<br />
* [http://home.arcor.de/m3ep/tut_colorpicking/tut_colorpicking_src.zip Quellcode des Beispieles]<br />
* [http://home.arcor.de/m3ep/tut_colorpicking/tut_colorpicking_exe.zip Vorkompilierte Version des Beispieles (Windows)]<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=24101Tutorial ColorPicking Shader2009-08-08T01:58:41Z<p>Waran: /* Objektselektion mit Color Picking */</p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bot bisher leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren. Für Einsteiger mit weniger großen Ambitionen empfiehlt sich aber vorerst eher die [[Tutorial ColorPicking|shaderlose Variante]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welche mit einfacheren Mitteln auskommt.<br />
<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den {{ArchivLink|file=tut_colorpicking_src|text=restlichen Code}} analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts. Damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(y) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt<br />
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches<br />
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber<br />
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern<br />
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas<br />
absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die<br />
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich<br />
wieder beim Immediate Mode landen und hättet <i>trotz</i> Listen, die durch die<br />
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,<br />
nichts gewonnen.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern<br />
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken<br />
und ganz nebenbei die caching performance des Treibers zu erhöhen. <br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (siehe unten) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
== Dateien ==<br />
* {{ArchivLink|file=tut_colorpicking_src|text=Quellcode des Beispieles}}<br />
* {{ArchivLink|file=tut_colorpicking_exe|text=Vorkompilierte Version des Beispieles (Windows)}}<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=24032Tutorial ColorPicking Shader2009-08-05T04:24:47Z<p>Waran: </p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bot bisher leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren. Für Einsteiger mit weniger großen Ambitionen empfiehlt sich aber vorerst eher die [[Tutorial ColorPicking|shaderlose Variante]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welche mit einfacheren Mitteln auskommt.<br />
<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den {{ArchivLink|file=tut_colorpicking_src|text=restlichen Code}} analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt<br />
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches<br />
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber<br />
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern<br />
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas<br />
absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die<br />
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich<br />
wieder beim Immediate Mode landen und hättet <i>trotz</i> Listen, die durch die<br />
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,<br />
nichts gewonnen.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern<br />
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken<br />
und ganz nebenbei die caching performance des Treibers zu erhöhen. <br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (siehe unten) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
== Dateien ==<br />
* {{ArchivLink|file=tut_colorpicking_src|text=Quellcode des Beispieles}}<br />
* {{ArchivLink|file=tut_colorpicking_exe|text=Vorkompilierte Version des Beispieles (Windows)}}<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=24009Tutorial ColorPicking Shader2009-08-03T19:34:32Z<p>Waran: /* Einleitung */</p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bot bisher leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Für Einsteiger mit weniger großen Ambitionen empfiehlt es sich aber eher das [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]) welches mit einfacheren Mitteln zurecht kommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den {{ArchivLink|file=tut_colorpicking_src|text=restlichen Code}} analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt<br />
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches<br />
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber<br />
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern<br />
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas<br />
absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die<br />
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich<br />
wieder beim Immediate Mode landen und hättet <i>trotz</i> Listen, die durch die<br />
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,<br />
nichts gewonnen.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern<br />
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken<br />
und ganz nebenbei die caching performance des Treibers zu erhöhen. <br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
== Dateien ==<br />
* {{ArchivLink|file=tut_colorpicking_src|text=Quellcode des Beispieles}}<br />
* {{ArchivLink|file=tut_colorpicking_exe|text=Vorkompilierte Version des Beispieles}}<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=24008Tutorial ColorPicking Shader2009-08-03T18:29:39Z<p>Waran: /* Die Renderschleife */</p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bietet momentan leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Für Einsteiger mit weniger großen Ambitionen empfiehlt es sich aber eher das [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]) welches mit einfacheren Mitteln zurecht kommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den {{ArchivLink|file=tut_colorpicking_src|text=restlichen Code}} analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt<br />
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches<br />
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber<br />
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern<br />
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas<br />
absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die<br />
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich<br />
wieder beim Immediate Mode landen und hättet <i>trotz</i> Listen, die durch die<br />
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,<br />
nichts gewonnen.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern<br />
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken<br />
und ganz nebenbei die caching performance des Treibers zu erhöhen. <br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
== Dateien ==<br />
* {{ArchivLink|file=tut_colorpicking_src|text=Quellcode des Beispieles}}<br />
* {{ArchivLink|file=tut_colorpicking_exe|text=Vorkompilierte Version des Beispieles}}<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=24002Tutorial ColorPicking Shader2009-08-03T10:58:08Z<p>Waran: </p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bietet momentan leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Für Einsteiger mit weniger großen Amibationen empfiehlt es sich aber eher das [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]) welches mit einfacheren Mitteln zurecht kommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performanceaspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder Verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z restlichen Code] analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations bedingt<br />
der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber kann sie also in ein internes Format umwandeln, welches<br />
das volle Spektrum an Optimierungen und Cachetricks unterstüzt. Der Treiber<br />
erhält alle Daten "am Stück" und kann sich 100%ig auf das Rendern<br />
"konzentrieren", weil der Benutzer gar nicht die Möglichkeit erhält, irgendetwas<br />
absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
Es bringt auch nichts, die Displaylisten "unverbindlicher" zu halten und die<br />
Spezifika wie Farbe in der Renderschleife festzulegen - damit würdet ihr nämlich<br />
wieder beim Immediate Mode landen und hättet <i>trotz</i> Listen, die durch die<br />
Mischung mit Immediate Mode nicht mehr optimierbar und damit nutzlos geworden sind,<br />
nichts gewonnen.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
Bedenkt auch, dass ihr mehrmals verwendete Vertices nicht mehrfach speichern<br />
müsst. Benutzt stattdessen indizierte Arrays um den Speicherverbrauch zu senken<br />
und ganz nebenbei die caching performance des Treibers zu erhöhen. <br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte, macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch drei Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Performance&diff=23977Performance2009-08-02T23:02:07Z<p>Waran: /* Performance Killer */ "Fiat Tutorial" - und es entstand.</p>
<hr />
<div>__TOC__<br />
<br />
Dieser Artikel liefert einige Tipps dazu wie man eine OpenGL-Anwendung optimieren kann. Einige der hier genannten Tipps schließen sich gegenseitig aus. Welche Vorgehensweise die beste ist hängt immer davon ab wo gerade der Engpass liegt. Es bringt zum Beispiel wenig den Shader zu optimieren, wenn eigentlich die zu langsame CPU das Problem ist.<br />
<br />
=== Grundlagen ===<br />
Die folgenden Tipps sind eigentlich Pflicht, insbesondere da sie meist leicht zu realisieren sind. Beherzigt man diese überhaupt nicht, muss man sich nicht über eine unglaublich langsame Anwendung wundern. Die Reihenfolge gibt so ungefähr die Wichtigkeit an.<br />
# Schließe nicht sichtbare Polygone so schnell wie möglich vom Rendering aus.<br />
#* Aktiviere [[Backface Culling]].<br />
#* Benutze [[Frustum Culling]].<br />
#* Vor allem bei statischer Geometrie (die sich nicht bewegt) bieten sich die etablierten [[Techniken_und_Algorithmen#Raumunterteilungstechniken|Raumunterteilungstechniken]] wie BSP-Tree, Quad-Tree, usw. an.<br />
# Vermeide Kommunikation zwischen CPU und GPU.<br />
#* Lade nicht deine Texturen/Vertexdaten in jedem Frame neu auf die Grafikkarte hoch. Vermeide den Immediate Mode, also [[glBegin]]() und [[glEnd]](). Sofern du aber nur ein, zwei einzelne Dreiecke rendern möchtest ist der Immediate Mode akzeptabel.<br />
#* Verwende [[VBO|Vertexbuffer-Objects]] oder [[Displayliste]]n.<br />
# Verwende glDraw***-Aufrufe sparsam. Hiermit sind ALLE Befehle gemeint die irgendetwas rendern, z.B. [[glDrawArrays]], [[glDrawElements]], ..., aber auch [[glMultiDrawArrays]], usw...<br />
#* Lieber ein paar Polygone mehr rendern, wenn du dadurch glDraw***-Aufrufe einsparen kannst.<br />
#* Es spielt so gut wie keine Rolle, ob du 500 oder 1 Polygon renderst, da ein glDraw***-Aufrufe alleine schon ziemlich viel Zeit braucht.<br />
# Optimiere deine Modelle. Nutze den Mesh-Optimierer in deiner 3D-Modellierungssoftware. Dies bringt zwar meist nicht viel, ist aber ja auch nicht mehr als ein Knopfdruck.<br />
# Die Grafikkarte hat einen Cache für bereits vom Vertexshader verarbeitete Vertices. Dieser wird genutzt, wenn du [[Indices]] verwendest. Der Vertexshader muss also im optimalen Fall für jeden Vertex nur einmal ausgeführt werden, auch wenn der Vertex in mehreren Dreiecken verwendet wird. In jedem [[Mesh|geschlossenen]] und [[Mesh|2-mannigfaltigen]] Dreiecksnetz wird jeder Vertex im Durchschnitt von 6 Dreiecken verwendet. Hier lässt sich also so einiges an Speicher und Rechenleistung sparen.<br />
# Nutze den Z-Buffer aus.<br />
#* Sortiere nicht deine Polygone einzeln nach der Entfernung zur Kamera (Painters-Algorithm), sondern verwende den Z-Buffer.<br />
#* Sofern du aufwendige Shader oder viele Texturen verwendest, rendere deine Objekte (nicht Polygone) von vorne nach hinten. Also grob sortieren und den Rest den Z-Buffer machen lassen.<br />
#* Wenn du transparente Objekte hast, rendere zunächst von die undurchsichtigen Objekte. Die transparenten Objekte renderst du dann sortiert von hinten nach vorne.<br />
# Vermeide wenn möglich häufige Shader-, Textur-, Material- und Statewechsel.<br />
<br />
===Performance Killer===<br />
# Die OpenGL eigene Selektion wird nur schlecht als recht unterstützt. Eine [[Tutorial_ColorPicking|Color-Picking-Selection]] kann abhilfe leisten.<br />
# [[glPushAttrib]] und glPopAttrib gelten laut [http://ati.amd.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf diesem ATI Dokument] als "State Evils", welche sich negativ auf die Performance auswirken.<br />
# Sofern die Extension [http://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt GL_ARB_texture_non_power_of_two] nicht unterstützt wird, könnte eine Grafikkarte bei Texturen deren Kantenlänge keiner 2er-Potenz entspricht (also z.B. 256, 512, 1024, ...) in den Software-Modus umschalten. Im Software-Modus wird die Grafikkarte komplett von der CPU emuliert. Das dies nicht schnell sein kann dürfte klar sein.<br />
<br />
=== Fortgeschrittene Techniken ===<br />
Die folgenden Tipps sind nicht so einfach zu realisieren oder erfordern Kenntnisse über fortgeschrittene Features wie Shader, Instancing. Die Reihenfolge der Tipps ist hier nicht von Bedeutung.<br />
# Ein glDraw*** wird nicht sofort ausgeführt, d.h. die CPU erhält die Kontrolle zurück bevor die GPU fertig mit rendern ist. Erst beim vertauschen von Front- und Backbuffer ("[[SwapBuffers]]") oder einem expliziten [[glFinish]] wird synchronisiert. Folglich gebe zuerst der Grafikkarte was zu arbeiten, rechne dann deine Spiellogik, Physik, etc. auf der CPU und rufe dann erst [[SwapBuffers]] auf. Sowas geht natürlich nicht immer, aber man kann beispielsweise Physik und Rendern in zwei Frames aufspilten. Also du berechnest immer die Physik für das nächste Frame, während die GraKa das aktuelle Frame rendert. Siehe auch [[glFlush]].<br />
# Überlege ob du Grafikspeicher sparen kannst indem du z.B. Texturkoordinaten oder Normalen zur Laufzeit im [[Shader]] berechnest.<br>(Beispiel: [[Shader#Beispiel:_Heightmap-Terrain|Heightmap-Terrain]])<br />
# Wenn du viele identische Objekte renderst, überlege ob du [[GL_ARB_draw_instanced|Instancing]] einsetzen kannst. Erfordert allerdings halbwegs aktuelle Grafikhardware.<br />
# Überlege ob du aufwendige Berechnungen, z.B. ein [[GLSL_Partikel_2|Partikelsystem]], nicht besser vollständig auf der Grafikkarte realisierst. Stichworte: [[Tutorial_Framebufferobject|Framebuffer-Objects]] und [[Shader#Transform-Feedback_(auch_Stream-Out)|Transform-Feedback]].<br />
# Verzichte auf einen [[Shader|Geometryshader]], wenn du ihn nicht unbedingt benötigst.<br />
# Mit [[Triangulation|Triangle Strips]] lässt sich die Anzahl der notwendigen Vertices (bzw. Indices) bis auf ein Drittel reduzieren. Auch hier kommt der Vertexcache der Grafikkarte zum Einsatz.<br />
# Überlege ob du deine Modelle immer in höchster Detailstufe ( mit Texturierung, Beleuchtung und anderen teuren Effekten ) zeichnen musst, wenn nicht, verwende [[LOD]] ( ''Level-Of-Detail'' ).<br />
# Überlege ob du bei statischen Szenen komplexe Beleuchtungsberechnungen durch [[Lightmaps]] ersetzen kannst. Lightmaps benötigen zwar einiges an Grafikspeicher, jedoch müssen Berechnungen z.B. für Schatten nur einmal durchgeführt werden. Dies funktioniert sowohl bei [[GLSL_Licht_und_Schatten|Shadow Maps]] als auch bei [[Volumetrische_Stencilschatten|volumetrischen Stencilschatten]]. Auch [[Reflexion]]en oder [[Kaustik]]en stellen kein Problem dar.<br />
<br />
=== Shader ===<br />
Die folgenden Tipps beschäftigen sich mit der Optimierung von [[Shader]]n. Auch hier ist die Reihenfolge nicht von Bedeutung.<br />
# Vermeide den Universal-Shader. Shader-Wechsel sind zwar aufwendig, aber eine gigantische if-Verzweigung die für jeden Vertex und jeden Pixel (!) ausgeführt werden muss ist noch wesentlich aufwendiger. Optimiere deinen Shader für die Aufgabe die er erfüllen muss.<br />
# Vermeide aufwendige Berechnungen im Shader. Möglicherweise ist es sinnvoll komplexe Berechnungen im voraus zu berechnen und im Shader eine Lookup-Textur zu verwenden. Sofern eine komplexe Berechnung nur von Uniform-Variablen abhängig ist, ist es oft sinnvoll einfach eine weitere Uniform-Variable zu spendieren und einmal auf der CPU zu berechnen.<br />
# Verwende nach Möglichkeit die in GLSL [[Tutorial_glsl#Eingebaute_Funktionen|integrierten Funktionen]]. Diese Funktionen können zum Teil wesentlich schneller sein da sie zum Teil direkt in der Hardware implementiert sind.<br />
# Optimiere deine Shader so weit wie möglich. Effizienz hat hier Vorrang vor der Lesbarkeit, da die Operationen möglicherweise millionenfach pro Frame ausgeführt werden. Im Fall der Fälle dann einfach mal etwas ausführlicher kommentieren. <br />
# Versuche insbesondere aufwendige Operationen wie zum Beispiel eine Wurzel zu vermeiden. Bedenke das sich solche Operationen auch in eingebauten Funktionen wie beispielsweise {{INLINE_CODE|length}}, {{INLINE_CODE|distance}} und {{INLINE_CODE|normalize}} verstecken können.<br />
# Vermeide Random-Access auf Texturen. Zwei nebeneinander liegende Texel einer Textur können üblicherweise schneller aus dem Speicher geladen werden als zwei Texel an völlig unterschiedlichen Positionen in der Textur. Nutze den GPU-Cache!<br />
# Versuche nicht Speicher zu sparen in dem du Variablen im Shader zusammenfasst. Beispielsweise macht eine Variable {{INLINE_CODE|vec4 positionAndSize}} wenig Sinn, wenn Position und Größe nur wenig miteinander zu tun haben und du z.B. ständig mit {{INLINE_CODE|positionAndSize.xyz}} arbeitest. Verwende lieber separate Variablen, also {{INLINE_CODE|vec3 position}} und {{INLINE_CODE|float size}}. So kann der Compiler besser optimieren.<br>Dies gilt natürlich nur für lokale Variablen im Shader. Wenn du mit dieser Methode Werte in einer Textur zusammenfassen kannst ist dies natürlich sehr sinnvoll!<br />
# Es gibt diverse Tools mit denen du feststellen kannst wo genau deine Anwendung die meiste Zeit benötigt bzw. wo du optimieren solltest.<br />
#* [http://developer.nvidia.com/object/nvperfkit_home.html NVIDIA PerfKit]<br />
#* [http://news.developer.nvidia.com/2006/12/nvidia_perfgrap.html NVIDIA PerfGraph]<br />
#* [http://developer.amd.com/gpu/shader/Pages/default.aspx AMD GPU ShaderAnalyzer]<br />
#* bitte ergänzen...<br />
<br />
=== Quellen / Links ===<br />
* [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GPU Programming Guide]<br />
* [http://ati.amd.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf OpenGL Performance Tuning, GDC 2006]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=23976Tutorial ColorPicking Shader2009-08-02T20:36:12Z<p>Waran: </p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bietet momentan leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Wenn es darum geht, sich "nur" schnell mit der grundlegenden Theorie zu<br />
befassen, um dann im Rahmen kleiner Übungsprojekte Objekte anklicken zu können,<br />
rate ich zunächst zum [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welches ganz ohne Shader oder<br />
Berücksichtigung des internen Aufbaus von Grafiktreiber und Speicher auskommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performance-aspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-Variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z restlichen Code] analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-Prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations-<br />
bedingt der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber stellt aus diesen Displaylisten beim GL_COMPILE-Vorgang<br />
ein statisches Vertex Buffer Object her, welches extrem effizient von der<br />
Grafikkarte bearbeitet werden kann. Der Treiber erhält alle Daten "am Stück" und<br />
kann sich 100%ig auf das Rendern "konzentrieren", weil der Benutzer gar nicht<br />
die Möglichkeit erhält, irgendetwas absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte - macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch 3 Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_Objektselektion&diff=23975Tutorial Objektselektion2009-08-02T20:33:55Z<p>Waran: /* Download */ Navigation geupdated</p>
<hr />
<div>=Objektselektion=<br />
<br />
==Einleitung==<br />
Manchmal ist es nötig, zu wissen, welches auf den Schirm gebrachte Objekt vom Benutzer angewählt wurde. Egal ob man es für einen Karteneditor benötigt, um zu erfahren, welche Wand angeklickt wurde, oder für ein Strategiespiel, um herauszufinden, welches Gebäude angewählt wurde, es ist sehr einfach zu implementieren. Da ich noch keine guten Tutorials über OpenGLs Selection-Modus (besonders in Delphi) gesehen habe und diesen für den Karteneditor der ZornGL Engine benötigte, habe ich mich dran gemacht, herauszufinden wie diese Technik zu nutzen ist und werde es Ihnen in diesem Tutorial zeigen.<br />
<br />
<br />
==Schritt 1 - Die Objektnamen auf den Name Stack legen==<br />
Das Wichtigste am Selection Modus ist der Name Stack. Dies ist der Platz, an dem OpenGL die "Namen" der Objekte (trotz der Bezeichnung "Name" handelt es sich um Integer Werte) ablegt, die später zur Erkennung des gewählten Objekts zurückgegeben werden. Wie mit allen anderen OpenGL Stacks kann man Namen auf den Stack legen. Obwohl man auch Namen von diesem Stack herunternehmen kann, wird man davon kaum Nutzen machen. Beachten Sie, dass alle Kommandos zur Manipulation des Name Stacks nur im Selection Modus funktionieren, dazu aber später mehr. Sehen Sie sich zuerst dieses kleine Beispiel und seine Beschreibung an:<br />
<br />
<br />
<source lang="pascal">const<br />
Sun = 1;<br />
Mars = 2;<br />
Earth = 3;<br />
Moon = 4;<br />
<br />
procedure TGLForm.DrawScene;<br />
begin<br />
glInitNames;<br />
glPushName(0);<br />
...<br />
glLoadName(Sun);<br />
glCallList(SunList);<br />
...<br />
glLoadName(Mars);<br />
glCallList(MarsList);<br />
...<br />
end;</source><br />
<br />
<br />
Die Nutzung des Selection Modus ist - wie Sie sehen können - sehr einfach. Zuerst müssen Sie den Name Stack leeren and dann muss mindestens ein Name auf den Stack gelegt werden. Wenn Sie dies nicht tun, wird der nächste [[glLoadName]]-Befehl keinen Namen auf den Stack legen, sondern einen GL_INVALID_OPERATION-Fehler auslösen.<br />
<br />
Nachdem der Name Stack also ordnungsgemäß initialisiert wurde, laden wir für jedes Objekt in unserer Szene (oder besser alle Objekte, die der Nutzer auswählen kann) einen Namen. Nach dem Laden des Namens zeichnen Sie Ihr Objekt. Dabei macht es keinen Unterschied ob dies eine Displayliste ist oder durch [[glBegin]] und [[glEnd]] geschieht.<br />
<br />
<br />
==Schritt 2 - Die ausgewählten Objekte finden==<br />
Jetzt kommen wir zum Kern der Sache: Herauszufinden, welches Objekt unter dem Cursor liegt. Dies ist ein wenig komplizierter, aber sehen Sie sich dazu einfach folgende Prozedur und ihre Beschreibung an:<br />
<br />
<br />
<source lang="pascal">function TGLForm.GetSelectBufferHit : Integer;<br />
var<br />
SelectBuffer : array[0..512] of TGLUInt;<br />
Viewport : TGLArrayi4;<br />
Hits,i : Integer;<br />
HitZValue : TGLUInt;<br />
Hit : TGLUInt;<br />
begin<br />
glGetIntegerv(GL_VIEWPORT, @viewport);<br />
glSelectBuffer(512, @SelectBuffer);<br />
glRenderMode(GL_SELECT);<br />
glInitNames;<br />
glPushName(0);<br />
glMatrixMode(GL_PROJECTION);<br />
glPushMatrix;<br />
glLoadIdentity;<br />
gluPickMatrix(mx, viewport[3]-my, 1.0, 1.0, viewport);<br />
gluPerspective(45.0, ClientWidth/ClientHeight, 0.1, 1000);<br />
DrawScene;<br />
glMatrixMode(GL_PROJECTION);<br />
glPopMatrix;<br />
Hits := glRenderMode(GL_RENDER);<br />
Hit := High(TGLUInt);<br />
HitZValue := High(TGLUInt);<br />
for i := 0 to Hits-1 do<br />
if SelectBuffer[(i*4)+1] < HitZValue then<br />
begin<br />
Hit := SelectBuffer[(i*4)+3];<br />
HitZValue := SelectBuffer[(i*4)+1];<br />
end;<br />
Result := Hit;<br />
end;</source><br />
<br />
<br />
Wenn Sie die Variablendeklaration dieser Funktion betrachten, werden Sie sehen, dass ein Array namens SelectBuffer benötigt wird. Dies ist der Platz an dem OpenGL alle Treffer mit ihren Z-Werten speichern wird. Ein weiterer Nachteil des Selection-Modus ist die Tatsache, dass die Anzahl der Treffer, die man bekommt nicht bekannt ist. Deshalb muss ein Array fester Größe genutzt werden, was jedoch aufgrund der Tatsache, dass dies lokal deklariert ist, keine Probleme macht.<br />
<br />
Nach dem Sichern unseres Blickfeldes nutzen wir den Befehl [[glSelectBuffer]]''(size : Integer; buffer : PGLUint)'' um OpenGL die Größe und die Adresse unseres SelectBuffers mitzuteilen.<br />
<br />
Nun wechseln wir mit Hilfe des [[glRenderMode]]''(mode : cardinal)''-Befehls vom Rendermodus in den Selection-Modus, initialisieren den Name Stack und legen einen Namen auf ihn.<br />
<br />
Danach ist es Zeit, eine neue Projekionsmatrix zu erstellen. Da wir wollen, dass der Nutzer ein Objekt durch einen Mausklick anwählen kann, erstellen wir mit [[gluPickMatrix]]''(x, y, width, height: TGLdouble; viewport: TVector4i)'' eine neue Matrix, die an der Mausposition zentiert wird und 1x1 Pixel groß ist.<br />
<br />
Nach einem erneuten Setzen des FOV, des Aspektratios- und des zFar-Wertes zeichnen wir unsere Szene erneut. Diesmal wird sie jedoch im Selection-Modus gezeichnet und alle den Name Stack betreffenden Befehle werden jetzt ausgeführt.<br />
<br />
Nachdem wir unsere Projektionsmatrix wiederhergestellt haben, wechseln wir wieder in den Rendermodus. Aber diesmal gibt der [[glRender]]-Befehl die Anzahl der Objekttreffer zurück, die wir für die spätere Nutzung speichern.<br />
<br />
Da wir jetzt also die Zahl der Treffer kennen, ist es sehr einfach, das vom Nutzer gewählte Objekt zu finden. Wie Sie wissen sollten, ist dies das Objekt mit dem niedrigsten Z-Wert (also das mit der geringsten Entfernung zum Betrachter).<br />
Um dieses zu finden muss man erst wissen, was sich im SelectionBuffer befindet. Der Puffer besteht aus Trefferrecords, der wiederum aus folgenden Teilen besteht:<br />
<br />
*Anzahl der Namen auf dem Stack zum Zeitpunkt des Treffers<br />
*Kleinste z-Koordinate aller Eckpunkte des gewählten Objekts<br />
*Größte z-Koordinate aller Eckpunkte des gewählten Objekts<br />
*Name des getroffenen Objekts<br />
<br />
Die einzigen benötigten Einträge sind der Zweite und der Letzte. Auf diese kann mit SelectBuffer[(n*4)+1] und SelectBuffer[(n*4)+3] zugegriffen werden, wobei n der gerade bearbeitet Treffer ist. Genau dies tut obige Prozedur in der am Ende gestarteten Schleife. Wenn die z-Koordinate des Treffers niedriger ist als die gespeicherte, wird sie durch selbige ersetzt. Außerdem wird gleichzeitig der Name des Treffers gespeichert.<br />
Wenn die Schleife durchlaufen ist, haben wir also den Namen des Objektes, das sich unter dem Mauszeiger befand!<br />
<br />
<br />
==Das Beispielprogramm==<br />
Ich habe ein kleines Beispielprogramm geschrieben, das ein winziges Universum simuliert.Beim Klick auf einen der Planeten sehen Sie im unteren Panel dessen Namen.<br />
<br />
<br />
[[Bild:Tutorial_Selection_selection01.jpg|center]]<br />
<br />
<br />
==Download==<br />
[http://delphigl.de/files/selectiontut.zip Das Selektionsdemo (inklusive Quellcode) herunterladen]<br />
<br />
<br />
<br />
Autor: [[Benutzer:Sascha_Willems|Sascha Willems]]<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Selection]]|[[Tutorial ColorPicking]]}}<br />
<br />
[[Kategorie:Tutorial|Objektselektion]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=23973Tutorial ColorPicking Shader2009-08-02T18:17:55Z<p>Waran: /* Vertex Array / VBO */</p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bietet momentan leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Wenn es darum geht, sich "nur" schnell mit der grundlegenden Theorie zu<br />
befassen, um dann im Rahmen kleiner Übungsprojekte Objekte anklicken zu können,<br />
rate ich zunächst zum [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welches ganz ohne Shader oder<br />
Berücksichtigung des internen Aufbaus von Grafiktreiber und Speicher auskommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performance-aspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z restlichen Code] analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-<br />
prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations-<br />
bedingt der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das Kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber stellt aus diesen Displaylisten beim GL_COMPILE-Vorgang<br />
ein statisches Vertex Buffer Object her, welches extrem effizient von der<br />
Grafikkarte bearbeitet werden kann. Der Treiber erhält alle Daten "am Stück" und<br />
kann sich 100%ig auf das Rendern "konzentrieren", weil der Benutzer gar nicht<br />
die Möglichkeit erhält, irgendetwas absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
<br />
# Der Treiber muss seine Daten "am Stück" erhalten können.<br />
# Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
# Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
* Vertices<br />
* Farbdaten oder Texturkoordinaten<br />
* Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte - macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch 3 Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=23972Tutorial ColorPicking Shader2009-08-02T16:55:42Z<p>Waran: </p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bietet momentan leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Wenn es darum geht, sich "nur" schnell mit der grundlegenden Theorie zu<br />
befassen, um dann im Rahmen kleiner Übungsprojekte Objekte anklicken zu können,<br />
rate ich zunächst zum [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welches ganz ohne Shader oder<br />
Berücksichtigung des internen Aufbaus von Grafiktreiber und Speicher auskommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performance-aspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z restlichen Code] analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-<br />
prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations-<br />
bedingt der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das Kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber stellt aus diesen Displaylisten beim GL_COMPILE-Vorgang<br />
ein statisches Vertex Buffer Object her, welches extrem effizient von der<br />
Grafikkarte bearbeitet werden kann. Der Treiber erhält alle Daten "am Stück" und<br />
kann sich 100%ig auf das Rendern "konzentrieren", weil der Benutzer gar nicht<br />
die Möglichkeit erhält, irgendetwas absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
1) Der Treiber muss seine Daten "am Stück" erhalten können.<br />
2) Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
3) Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
- Vertices<br />
- Farbdaten oder Texturkoordinaten<br />
- Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte - macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch 3 Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
<br />
<br />
{{TUTORIAL_NAVIGATION|[[Tutorial Objektselektion]]|[[Tutorial TexFilter]]}}<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial_ColorPicking_Shader&diff=23971Tutorial ColorPicking Shader2009-08-02T16:51:01Z<p>Waran: Die Seite wurde neu angelegt: „=Objektselektion mit Color Picking= ==Einleitung== Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn ich euch sage, dass es dafür au...“</p>
<hr />
<div>=Objektselektion mit Color Picking=<br />
<br />
==Einleitung==<br />
<br />
Jaja, schon das dritte Selektionstutorial auf DelphiGL. Aber glaubt mir wenn<br />
ich euch sage, dass es dafür auch gute Gründe gibt. DGL bietet momentan leider<br />
nur Tutorials, die das Picking auf Basis von OpenGLs Namestack behandeln. Diese<br />
Methode ist aber gerade für Einsteiger ungeeignet, nicht etwa, weil sie<br />
unnötig kompliziert wäre, aber weil sie hoffnungslos veraltet, tendenziell<br />
inkompatibel zu nVidias Treibern (Softwaremodus!) und enorm unflexibel ist.<br />
Jedenfalls war es kein Anflug aus purer Bosheit, der die Khronos-Group dazu<br />
bewogen hat, diese Methode in OpenGL3 zu entfernen.<br />
<br />
Ein Wort zur angestrebten Zielgruppe:<br />
Bedenkt bitte, dass das Tutorial eher darauf ausgelegt ist, euch eine<br />
performante, für große Projekte taugliche und vor allem zukunftssichere Methode<br />
zu präsentieren.<br />
<br />
Wenn es darum geht, sich "nur" schnell mit der grundlegenden Theorie zu<br />
befassen, um dann im Rahmen kleiner Übungsprojekte Objekte anklicken zu können,<br />
rate ich zunächst zum [[Tutorial von Tilman]] ([http://s200005540.online.de/verschiedenes/colorpicking.pdf Vorabversion als PDF]), welches ganz ohne Shader oder<br />
Berücksichtigung des internen Aufbaus von Grafiktreiber und Speicher auskommt.<br />
<br />
In diesem Tutorial soll es um Color Picking, also Selektion mithilfe von Farben,<br />
gehen. Damit ihr euch ein Bild davon machen könnt wo ihr steht, wenn ihr die<br />
Technik beherrscht, hier ein kurzer Überblick über die Vor- und Nachteile:<br />
<br />
<br />
<table><br />
<tr><br />
<td align="center"><b>Vorteile</b></td><br />
<td align="center"><b>Nachteile</b></td><br />
</tr><br />
<tr><br />
<td valign="top"><br />
* Geschwindigkeit<br />
:Ein Selektionsvorgang mit dieser Methode dauert niemals länger als ein ganz normales Rendering der Szene - i.d.R. ist es sogar schneller, da das Verfahren darauf aufbaut, viel "unter den Tisch fallen zu lassen".<br />
<br />
* Speichereffizienz<br />
:Im Gegensatz zu strahlbasierten Verfahren, die im Härtefall eine eigene Kollisionsgeometrie benötigen, funktioniert Color Picking mit Shadern "in place" und benötigt keinen zusätzlichen Speicher (oder nur vernachlässigbar wenig). Wird es ohne Shader implementiert, fallen mit jedem selektierbarem Objekt 3-4 Byte pro Vertex an (d.h. etwa 12 Bytes für ein Quad).<br />
<br />
* Flexibilität<br />
:Color Picking funktioniert mit jeder Grafik-Schnittstelle und jeder Art von Geometrie - das schließt 2D, 3D, animiert, dynamisch und alphamaskiert mit ein. Objekte müssen nicht, wie in diesem Beispiel, durch einen festen Index identifiziert werden, sondern können auch problemlos mit eigenen Werten oder sogar Funktionen versehen werden. Und das Beste:<br />
<br />
* Simplizität<br />
:Das Alles gibt es zum Preis eines kleinen Fragmentshaders. Mehr Aufwand ist kaum nötig, um so gut wie alle Sonderfälle abzudecken. Man kann als Fausregel festhalten: Alles was der Benutzer sieht, kann selektiert werden. Ohne Kompromisse! Pixelgenau. Ohne aufwändige Mathematik dahinter. Und alles _voll_ Hardwarebeschleunigt. Bei der shaderlosen Variante müssen sich allerdings ein paar Gedanken über die zugrundeliegende Geometrie gemacht werden (auch vom Performance-aspekt her betrachtet).<br />
</td><br />
<br />
<td valign="top"><br />
* Reproduzierbarkeit<br />
:Leider ist man bei einem hardwarebasierten Verfahren (trifft auf Color Picking mit OpenGL sowie Direct3D zu) auf Gedeih und Verderb dem Treiber ausgeliefert. Und damit hängt der Erfolg der Selektion theoretisch auch davon ab, wie gut sich der Treiberhersteller an Standards halten kann. Insbesondere Dinge wie Antialiasing können die Selektion verfälschen - in diesem Tutorial wird aber auch ein sehr effektiver Workaround dagegen angeboten. In der Praxis ist dieser Nachteil auch eher unbedeutend, weil man ein gewisses Maß an Standards durchaus vorraussetzen kann.<br />
<br />
* Redundanz zum Physikcode<br />
:Wenn alle mathematischen Grundlagen für eine Selektion via Raycasting geschaffen sind, wäre eine zusätzliche Implementierung von Color Picking nur Ballast. "Grundlagen für Raycasting" hört sich vielleicht abgehoben an, diese sind aber z.B. schon in einem einfachen Ego Shooter geschaffen, wenn man herauskriegen will, wo das Einschussloch gezeichnet werden soll oder welche Hitbox des Gegners getroffen wurde.<br />
<br />
* Hardwareanforderungen<br />
:Je mehr Features man nutzt (wie z.B. Shader), desto neuer muss die Grafikhardware sein. Die Methode, die hier im Tut vorgestellt wird, basiert auf GLSL und ist damit ab OpenGL 2.0 Core zu haben.<br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
==Theorie==<br />
<br />
Die Theorie hinter dem Color Picking ist ganz schnell erklärt. Man zeichnet<br />
jedes selektierbare Objekt in einer einmaligen Farbe und merkt sich, welches<br />
Objekt in welcher Farbe gezeichnet wurde.<br />
Dann wird ein Pixel unter dem Mauszeiger ausgelesen - anhand der ausgelesenen<br />
Farbe lässt sich auf das Objekt unter dem Mauszeiger zurückschließen. Das ist<br />
vielleicht momentan noch ein bisschen sehr abstrakt, sollte aber schon klarer<br />
werden, wenn ihr den Beispielcode verfolgt.<br />
<br />
<br />
==Implementierung==<br />
<br />
===Organisation===<br />
<br />
Vorweg muss gesagt sein: Wirklich alles was ich in dem Beispielcode mache, ist<br />
nur eine Lösung von vielen. Wie euch durch die kurze Theorie schon dämmern<br />
sollte gibt es etliche Möglichkeiten Color Picking zu implementieren. In diesem<br />
Beispiel sieht das Ganze so aus:<br />
Die Daten der selektierbaren Objekte (Displayliste, Position und ein String)<br />
sind in einem Record zusammengefasst. Alle diese Records sind in einem Array<br />
angeordnet und werden auch per Schleife gezeichnet... exakt dieser Array-Index<br />
ist es nun, was jedem individuellen Objekt seine Identifizierbarkeit spendiert.<br />
<br />
<br />
===Der Shader===<br />
<br />
Jeder der bei Shader an böhmische Dörfer denkt, sollte sich vielleicht vorher<br />
kurz das [[Tutorial glsl|GLSL-Tutorial]] auf DGL zu Gemüte führen. Prinzipiell handelt es sich<br />
um kleine Programme, die Teile der festen OpenGL-Pipeline (dazu gehört z.B.<br />
die Positionierung von Vertices und das Zeichnen oder verwerfen von Pixeln)<br />
ersetzen. Shader können entweder in Assembler oder einer Sprache namens GLSL<br />
in einer C-artigen Syntax geschrieben werden - in diesem Beispiel wird letztere<br />
Methode verwendet, da die Assemblervariante kaum noch weiterentwickelt wird und<br />
schlechter zu lesen ist.<br />
<br />
Sehen wir uns nun die Shader an, der vor einem Selektionsvorgang gebunden und<br />
anschließend wieder ausgeschaltet werden:<br />
<br />
<br />
<source lang="glsl"><br />
// Vertexshader<br />
<br />
void main(void)<br />
{<br />
gl_Position = ftransform();<br />
gl_TexCoord[0] = gl_MultiTexCoord0;<br />
}<br />
</source><br />
<br />
<br />
Der Vertexshader macht offensichtlich nichts (oder besser: nur) weltbewegendes.<br />
Jedes Vertex an seine Stelle setzen und Texturkoordinaten durchschleifen... aber<br />
da fehlt doch was? Der Vertexshader übergibt gar keine Farbdaten - d.h. wir<br />
können schonmal festhalten, dass die aktuelle Farbe in der Statemachine komplett<br />
<b>ignoriert</b> wird.<br />
<br />
<br />
<br />
<source lang="glsl"><br />
// Fragmentshader<br />
<br />
uniform vec4 color;<br />
uniform float use_alpha_tex;<br />
uniform sampler2D sampler;<br />
<br />
void main(void)<br />
{<br />
if (use_alpha_tex == 1.0)<br />
if (texture2D(sampler, vec2(gl_TexCoord[0])).a < 0.2)<br />
discard;<br />
<br />
gl_FragColor = color;<br />
}<br />
</source><br />
<br />
<br />
<br />
Hier sieht es schon gleich viel interessanter aus. Der Fragmentshader bekommt<br />
zwei im Programm gesetzte uniform Variablen: color und use_alpha_tex. Wie man in<br />
der letzten Zeile sieht, ist der Wert dieser ominösen color-variable genau das,<br />
was auch im Framebuffer erscheinen wird.<br />
<br />
"use_alpha_tex" wird im Programm auf 1.0 gesetzt, wenn Texturen mit Alphakanal <br />
verwendet werden.<br />
Sollen solche Texturen verwendet werden, liest der Shader den aktuellen<br />
Alphawert und verwirft das Fragment, wenn Alpha unter dem Schwellenwert 0.2<br />
liegt. Es handelt sich also nur um einen handgemachten Alphatest.<br />
<br />
Dabei sei angemerkt, dass dies kein sonderlich stilvolles Vorgehen ist: Man<br />
versucht möglichst, einen Shader nur auf eine ganz eng umrissene Aufgabe hin<br />
zu gestalten - da haben solche Abfragen nichts zu suchen. Es dient in diesem<br />
Tutorial aber der Übersichtlichkeit, also werden wir mal beide Augen zudrücken.<br />
<br />
Zusammenfassend kann man also sagen, dass wenn der Shader aktiviert ist, jedes<br />
einzelne gezeichnete Pixel eine von uns im Hauptprogramm festgelegte Farbe<br />
bekommt. Zusätzlich hat der Shader die Fähigkeit, bei Texturen mit Alphakanal<br />
"unsichtbare" Pixel zu ignorieren und damit den Hintergrund durchscheinen zu<br />
lassen.<br />
<br />
Tipp: Objekte mit Textur ohne Alphakanal zählen bei der Selektion wie Objekte<br />
ganz ohne Textur, da es sich letztendlich nur um ein Quad handelt, das in einer<br />
Einheitsfarbe eingefärbt werden soll.<br />
<br />
<br />
===Die Renderschleife===<br />
<br />
Sehen wir uns jetzt einmal den Code an, bei dem wirklich etwas gezeichnet wird.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render;<br />
const<br />
fac: single = 1/255;<br />
var<br />
i: longword;<br />
iv: array [0..3] of byte absolute i; // iv und i überschneiden sich<br />
</source><br />
<br />
<br />
<br />
Im Kopf der Prozedur sieht man schon erste Vorbereitungen auf das, was gleich<br />
während der Schleife passieren wird. Durch das absolute-Schlüsselwort überlappen<br />
i und iv im Speicher. Rein praktisch bedeutet das, dass man über iv auf die<br />
einzelnen Bytes der for-Variable i zugreifen kann, als wäre sie ein Byte-Array.<br />
<br />
Durch Multiplikation mit der Konstante fac wird ein Byte-Wert (0..255) in einen<br />
Float im Bereich (0..1) umgerechnet. Dies ist notwendig, da die Grafikkarte<br />
intern mit Floats arbeitet und man daher nur Floats übergeben kann (auf SM 4.0<br />
Karten funktioniert auch Integer, ist aber sehr unperformant).<br />
Das nächste Häppchen:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
begin<br />
glClear(GL_COLOR_BUFFER_BIT);<br />
<br />
// Das Erste Model soll texturiert werden<br />
glEnable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 1.0);<br />
<br />
for i := 1 to high(Objekte) do<br />
begin<br />
if i = 2 then begin // Ab dem zweiten nicht mehr<br />
glDisable(GL_TEXTURE_2D);<br />
glUniform1f(SelShader.use_alpha_tex, 0.0);<br />
end;<br />
</source><br />
<br />
<br />
<br />
Offensichtlich sind unsere Objekte im Array so angeordnet, dass zuerst<br />
texturierte Objekte (wir setzen use_alpha_tex auf 1.0 und aktivieren TEXTURE_2D)<br />
gezeichnet werden sollen. Diese Art von Sortierung macht Sinn, da Statechanges<br />
auf jeden Fall zu vermeiden sind, wenn sie vermeidbar sind. Gemeint ist mit<br />
Sortierung nicht, dass Alphatexturen zuerst kommen müssen, das ist manchmal auch<br />
gar nicht möglich, sondern das nicht mitten in der Schleife zwischen texturiert<br />
und nicht texturiert gewechselt werden muss. Bei dem zweiten Durchlauf wird die<br />
Texturierung deaktiviert und es geht ohne weiter (ergo: Es gibt nur ein<br />
texturiertes Objekt). Der interessante Teil der Renderfunktion folgt:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
// Den Index in eine Farbe umrechnen und im Shader setzen<br />
{$ifdef ENDIAN_BIG}<br />
glUniform4f(SelShader.color, iv[1]*fac, iv[2]*fac, iv[3]*fac, 1.0);<br />
{$else}<br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, 1.0);<br />
{$endif}<br />
<br />
// Zeichnen<br />
glLoadIdentity;<br />
glTranslatef(Objekte[i].posx, Objekte[i].posy, 0);<br />
glCallList(Objekte[i].displayliste);<br />
end;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Wie versprochen werden die 3 untersten (ich sage bewusst nicht "ersten") Bytes<br />
einzeln in Floats umgerechnet und landen in color.r, color.g und color.b des<br />
Shaders. color.a wird nicht verwendet und auf 1.0 gesetzt (1.0 ist der übliche<br />
Standardwert für Alpha). Mit dem so präparierten Shader würde nun gezeichnet<br />
werden, wäre er aktiviert.<br />
<br />
Die berechtigte Frage ist jetzt: Warum gibt es bei der Index-Umrechnung zwei<br />
verschiedene Varianten? Der Grund ist die sogenannte Endianess oder Byte Order.<br />
Bei Little-Endian-Systemen (z.B. x86) werden die Bytes mit höherer Adresse<br />
signifikanter, bei Big Endian (z.B. PowerPC, Playstation 3) ist es genau<br />
umgekehrt.<br />
<br />
Da wir nur 24 Bit (= 3 Byte) des Farbpuffers benutzen, interessiert uns das<br />
signifikanteste Byte des DWords nicht. Da dieses auf Big-Endian-Systemen<br />
gerade iv[0] ist, müssen die Offsets verschoben werden. Die folgende Grafik<br />
verdeutlicht dies:<br />
<br />
<br />
[[Datei:Endian.png|center]]<br />
<br />
<br />
Natürlich wird bei so einer einfachen Methode die Reihenfolge der<br />
Farbkomponenten verändert. Aus RGB auf Little Endian wird BGR auf Big Endian. Da<br />
wir die gefärbten Bilder allerdings sowiso nicht zu Gesicht bekommen, ist es<br />
egal.<br />
Ja, wir werden tatsächlich nie sehen können, was während der Selektion passiert.<br />
Oder hat jemand bis jetzt ein SwapBuffers ausmachen können? Nein? Gut, das muss<br />
so :3<br />
<br />
Wenn ihr den [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z restlichen Code] analysiert werdet ihr feststellen, dass SwapBuffers<br />
nur in der Eventschleife von SDL aufgerufen wird. Wenn Render in der Select-<br />
prozedur aufgerufen wird, werden die Buffer nicht getauscht (und damit das<br />
Bild nicht angezeigt).<br />
<br />
Erratum: Wie ihr seht wurde die Grafik von mir korrigiert. Ich habe mich<br />
entschlossen den Fehler nur durchzustreichen, damit ihr davon lernen könnt<br />
und ihn nicht wiederholt:<br />
Es handelt sich bei dieser Vorgehensweise NICHT um eine BITweise Verschiebung<br />
nach links (SHL 8), sondern um eine BYTEweise. Was macht das schon aus?<br />
Sehr viel! Wie "The Winner" mir freundlicherweise mitteilte, interpretiert die<br />
CPU bei bitweisen Operationen das LongWord "am Stück", also vom höchstwertigen<br />
zum untersten Bit von Links nach Rechts, damit bedeutet ein SHL unabhängig von<br />
der Plattform immer eine Multiplikation mit 2 (= Verschiebung um ein Bit in<br />
Richtung des am meisten signifikanten Bits).<br />
<br />
<br />
===Der Selektionscode===<br />
<br />
Ich hoffe ihr wurdet von dem Bit- und Bytegeschubse noch nicht gänzlich<br />
frustiert und überlegt, den Rest des Tutorials erstmal beiseite zu legen. Im<br />
Selektionscode (folgt) kommt noch ein bisschen mehr davon ^_^<br />
Bevor ich euch allerdings den Code gebe, solltet ihr erstmal wissen, was bei der<br />
Selektion genau gemacht wird.<br />
Anders als im kurzen Theorieteil besprochen lesen wir nicht nur einen Pixel,<br />
sondern eine 3x3-Box (9 Pixel) um den Mauszeiger herum aus. Das tun wir, um die<br />
Umgebung des Pixels zu untersuchen und damit Fehler durch Antialiasing sehr<br />
effektiv zu erkennen. Das Problem mit AA ist, dass es Mischfarben erzeugt: Das<br />
bedeutet wann man auf den Randbereich eines Objektes klickt, kann es sein, dass<br />
man nicht die Farbe des Objektes erwischt, sondern _irgend eine_ Mischfarbe.<br />
<br />
Wird diese kritiklos wieder als Index interpretiert landen wir irgendwo im<br />
Array und im besten Fall stürzt das Programm ab (im schlimmsten Fall passiert<br />
<i>nichts</i> und der Fehler bleibt uns bis zur Veröffentlichung erhalten).<br />
<br />
<br />
<br />
<source lang="pascal"><br />
function Select(x, y: integer): longword;<br />
var<br />
PixelData: array [0..9] of longword;<br />
count, i: longword;<br />
begin<br />
// Koordinaten umrechnen (SDL-Fenster in OpenGL / 3x3-Box zentrieren)<br />
y := WINDOW_Y-y;<br />
if x > 0 then if x < WINDOW_X then dec(x) else dec(x,2);<br />
if y > 0 then if y < WINDOW_Y then dec(x) else dec(y,2);<br />
</source><br />
<br />
<br />
<br />
Zuerst wird der "Mauszeiger" (eigentlich nur die Koordinaten, die wir bekommen<br />
haben) von Fensterpixeln (Ursprung oben) in OpenGL-Pixel (Ursprung unten)<br />
umgerechnet und wenn möglich nach unten links verschoben. Das verschieben sorgt<br />
dafür, dass die angeklickte Stelle genau in der Mitte der gleich ausgelesenen<br />
3x3-Box ist.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUseProgram(SelShader.prog);<br />
glClearColor(0.0, 0.0, 0.0, 0.0);<br />
glEnable(GL_SCISSOR_TEST);<br />
glScissor(x, y, 3, 3); // Die wenigsten Pixel müssen in den Buffer<br />
<br />
Render;<br />
// Kein SwapBuffers. Das codierte Bild sieht eh nicht hübsch aus.<br />
<br />
glUseProgram(0);<br />
glClearColor(0.1, 0.1, 0.1, 1.0);<br />
glDisable(GL_SCISSOR_TEST);<br />
</source><br />
<br />
<br />
<br />
Das Zeichnen sollte eigentlich selbsterklärend sein. Der Shader wird aktiviert,<br />
die Hintergrundfarbe auf (0 0 0 0) gesetzt (entspricht dem Index 0!) und der<br />
Scissor Test aktiviert. Der Test macht bei Selektion sehr viel Sinn, da wir uns<br />
ja eigentlich nur für 9 Pixel interessieren - warum dann alle im meinem Fall<br />
786.432 Pixel in den Framebuffer schreiben?<br />
In Anbetracht dessen, dass Scissor so gut wie kostenlos ist, wäre das eine<br />
unverzeiliche Sünde. Was der Test allerdings nicht verhindert ist, dass für<br />
jedes Pixel der Fragmentshader abgearbeitet werden muss - seht es also nicht als<br />
Freibrief für den Uber-Shader aus if-Abfragen.<br />
<br />
Aufgerufen wird die normale Render-Prozedur, die wir so angepasst haben, dass<br />
sie dem Shader, wenn er gebunden ist, die relevanten Daten zukommen<br />
lässt. Nehmt das als Anreiz euer Rendering bei großen Szenen gut zu optimieren<br />
(z.B. mit Octrees/BSP und Frustrum Culling) - eure Selektion profitiert genauso<br />
davon. Nach dem Rendering wird Alles zurückgesetzt und erhält damit wieder<br />
seine vorherige Ordnung.<br />
<br />
Jetzt kommt endlich der <b>wirklich</b> interessante Teil.<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glReadPixels(x, y, 3, 3, GL_RGBA, GL_UNSIGNED_BYTE, @PixelData[0]);<br />
<br />
count := 0;<br />
<br />
for i := 0 to 9 do<br />
begin<br />
if PixelData[4] = PixelData[i] then inc(count);<br />
<br />
if count > 3 then<br />
begin<br />
{$ifdef ENDIAN_BIG}<br />
result := (PixelData[4] shr 8)<br />
{$else}<br />
result := PixelData[4] and $FFFFFF;<br />
{$endif}<br />
exit;<br />
end;<br />
end;<br />
<br />
// Wenn diese Stelle erreicht wird, hat die Schleife nicht mehr als 3<br />
// gleichfarbige Pixel zusammenbekommen. Selektion ungültig.<br />
result := 0;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Interessant, aber es bleibt weiterhin einfach (ich hoffe es war einfach, bis<br />
jetzt ^^). Aus Vogelperspektive: Es werden 9 RGBA-Werte aus dem Framebuffer<br />
geholt - Alpha wird immer 255, da wird nur 24 Bit benutzen (Standardwert von<br />
OpenGL) - und in 9 DWords geschrieben.<br />
Schließlich wird gezählt, wie viele Pixel mit PixelData[4] (das ist die Mitte,<br />
der Mauszeigerpixel) identisch sind. Wenn es mindestens 4 Pixel sind, wird<br />
die Selektion für gültig erklärt - d.h. der Mauszeigerpixel wird in result<br />
geschrieben und die Funktion kehrt zurück.<br />
Wenn die Funktion in der Schleife noch nicht verlassen wurde, wird result auf 0<br />
gesetzt.<br />
<br />
Hier ein Beispiel in dem gezeigt wird, wie uns diesen Vorgehen hilft, Fehler zu<br />
Erkennen:<br />
<br />
<br />
[[Datei:AAc-Beispiel.png|center]]<br />
<br />
<br />
Der von mir festgesetzte Schwellenwert "4" (bedenkt dabei, dass implementations-<br />
bedingt der Pixel unter dem Mauszeiger mitgezählt wird) ist genaugenommen<br />
variabel. Theoretisch würde vermutlich auch 3 reichen, aber ich gehe da gerne<br />
auf Nummer sicher. Der Nachteil der Sicherheit ist, das man z.B. keine Linien<br />
mit 1px Breite selektieren kann - das Kleinste selektierbare Objekt hat die<br />
gezeichnete Größe von 2x2 Pixeln.<br />
<br />
Wie ihr seht, muss das LongWord vor der Rückgabe noch bearbeitet werden: Bei LE<br />
reicht es, den Alpha-Wert per Bitmaske abzuschneiden. Bei Big Endian landet der<br />
Alpha-Wert (glaube ich!) im untersten Byte. Daher muss in Richtung "unten"<br />
verschoben werden, damit der Alpha-Wert entfernt und unser Pixel-Index im<br />
unteren Bereich landet - schaut euch ruhig nochmal die Endian-Grafik an, wenn<br />
ihr jetzt nur Bahnhof versteht.<br />
Ich kann den Big Endian-Code leider mangels Maschine nicht testen. Sollte er<br />
also auf die Art nicht funktionieren, sofort in den IRC kommen oder mir eine PM<br />
schreiben (so kommt man auch an sein wohlverdientes Feedback).<br />
<br />
Und damit sind wir mit dem Thema durch. Was jetzt noch kommt ist lediglich für<br />
den Spezialfall interessant, wenn man mit 32-Bit selektieren will... kann ja<br />
sein, dass man die Bitschubserei satt hat oder 16.777.215 codierbare Objekte<br />
neben dem Hintergrund nicht genug sind :-)<br />
<br />
<br />
===Ergänzung: 32/16 Bit Farbtiefe===<br />
<br />
32 Bit sind eigentlich leichter handzuhaben, als 24 Bit. Das kommt daher, dass<br />
ein echter 32-Bit-Wert aus dem Framebuffer genau unserem (und eurem, gemeint<br />
sind die BEler) nativen LongWord entspricht und damit die ganze Bitschubserei<br />
inklusive Unterscheidung zwischen BE und LE überflüssig macht:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
glUniform4f(SelShader.color, iv[0]*fac, iv[1]*fac, iv[2]*fac, iv[3]*fac);<br />
</source><br />
<br />
<br />
<br />
<source lang="pascal"><br />
if count > 3 then<br />
begin<br />
result := PixelData[4];<br />
exit;<br />
end;<br />
</source><br />
<br />
<br />
<br />
Dazu kommt noch, dass wir auf einmal Raum für 4.294.967.295 Objekte haben, was<br />
definitiv mehr ist, als man jemals ausschöpfen könnte - an unsere<br />
mitzeitreisdenden Leser: Das Tutorial stammt von 2009, das war damals so ;-)<br />
<br />
Der Nachteil an 32 Bit zur Selektion (ja, jetzt wird es nochmal kurz ernst) ist,<br />
dass wir uns erstmal nicht darauf verlassen können, auch wirklich einen 32 Bit<br />
Buffer vom Treiber zu bekommen, wenn wir einen anfordern. Ohne Überprüfungen<br />
und Ausweichmöglichkeit auf 24 Bit läuft es also nicht.<br />
Daraus folgt? Genau - wir brauchen sowiso den 24 Bit-Code für solche Härtefälle.<br />
In Folge dessen ist der "Einfachheitsvorteil" von 32 Bit ad absurdum geführt<br />
und wir können getrost auf 24 Bit setzen.<br />
<br />
Ein noch gravierenderer Nachteil ist, dass wir nun auch auf OpenGL-Funktionen<br />
aufpassen müssen, die den Alphawert verwenden. Wenn beispielsweise Alphatest<br />
während der Selektion aktiviert ist, werden selbst mit einer kulanten<br />
Einstellung wie (GL_GREATER, 0.0) alle Selektionen von Objekten mit Alpha=0<br />
verworfen. Das sind auf Little Endian die ersten 16.777.215 und bei Big Endian<br />
jedes 256ste.<br />
<br />
Erlaubt der Treiber die Verwendung von lediglich 16 Bit, so wären noch 65535<br />
Objekte selektierbar. Das ist zwar in der Regel ebenfalls mehr als genug, aber<br />
leider erfordert 16 Bit aufgrund unterschiedlicher Bitlängen der Farbkomponenten<br />
(R: 5, G: 6, B: 5) einen enormen Aufwand bei der Zerlegung/Zusammensetzung des<br />
Index in/aus Farben, der nicht ohne massive Verwendung von Bitmasken und -shifts<br />
auskommt.<br />
Aus diesem Grund habe ich mich dazu entschlossen, das Thema "16 Bit" im Tutorial<br />
nicht weiter zu behandeln.<br />
<br />
<br />
==Shaderlose Variante (Anregung)==<br />
<br />
===Einleitung===<br />
<br />
In den letzten Kapiteln wurde die Implementierung mit Shadern besprochen. Diese<br />
bieten, wie schon am Anfang kurz in den Vorteilen angerissen, ein Maximum an<br />
Flexilibität und Speichereffizienz (da komplett unabhängig von der Geometrie)<br />
bei unbeeinträchtigter Performance. Im Prinzip eine Win-Win-Situation, könnte<br />
man meinen... leider gibt es aber auch noch Hardware, auf der keine Shader<br />
laufen.<br />
In diesem Kapitel soll es also darum gehen, euch eine Übersicht darüber zu<br />
geben, was in einer solchen Situation machbar ist - inklusive Bewertung im<br />
Kontext der angestrebten Zielgruppe (siehe "Einleitung"). Implementieren müsst<br />
ihr es dann aber selbst. Wenn euch die Shaderlose Variante nicht weiter<br />
interessiert, könnt ihr auch problemlos zum Schluss übergehen - ihr verpasst<br />
nichts mehr.<br />
<br />
Wesentlich schwieriger sind ohne Shader allerdings Spezialeffekte wie<br />
transparente Texturen. Eine Lösung sieht so aus, dass ihr zunächst das<br />
texturierte Objekt mit aktiviertem Alphatest in eine Stencil-Maske zeichnet.<br />
Danach wird in einem zweiten Pass ein Quad mit der Indexfarbe gezeichnet -<br />
durch die Maske werden nur solche Pixel geschrieben, die vorher den Alphatest<br />
bestanden und damit die Stencilmaske geformt haben.<br />
Nun aber zum grundlegenden Thema:<br />
<br />
Prinzipiell stehen euch ohne Shader zwei Möglichkeiten offen: 1) Einstreuen von<br />
Immediate Mode in eure Renderschleife oder 2) Anpassung der Geometrie.<br />
<br />
<br />
===Immediate Mode===<br />
<br />
Möglichkeit 1 sieht in Pseudocode folgendermaßen aus:<br />
<br />
<br />
<br />
<source lang="pascal"><br />
procedure Render(mode)<br />
<br />
if mode = rendermode<br />
Texturen aktivieren<br />
Lighting aktivieren<br />
usw.<br />
if mode = selection<br />
Texturen deaktiveren<br />
Lighting deaktivieren<br />
usw.<br />
<br />
foreach i in models<br />
if mode = rendermode<br />
Normale Farbe[i] setzen oder Textur binden<br />
if mode = selection<br />
glColor3ubv(@i) // nur Little Endian...<br />
<br />
Farblose(!) Geometrie[i] zeichnen<br />
</source><br />
<br />
<br />
<br />
Der Vorteil wird schnell ersichtlich: Die Methode bleibt flexibel und einfach<br />
handzuhaben - bei gleichzeitig guter Speichereffizienz. Was auf diese Art aber<br />
leider niemals erreicht wird ist maximale Performance.<br />
Durch die Verwendung von Immediate Mode wird dem Treiber jede Möglichkeit<br />
geraubt, den Rendervorgang zu optimieren. Gleichzeitig kann der Treiber auch<br />
keine Daten cachen (und ggf. wiederverwenden) sondern muss im Gegenteil noch<br />
Leistung dafür verbrauchen, jederzeit auf jeden Fehltritt von euch vorbereitet<br />
zu sein. Die Methode stößt also schnell an ihre Grenzen, wenn große Mengen<br />
von Daten verarbeitet werden sollen.<br />
<br />
<br />
===Vertex Array / VBO===<br />
<br />
Betrachtet man Möglichkeit 2 genauer, stellt man fest, dass es auch hier wieder<br />
mehrere Optionen gibt.<br />
Die Displaylisten, die im Shaderteil verwendet werden, sind<br />
<i>state complete</i>. Das bedeutet, sie enthalten alle Informationen, die der<br />
Treiber zum zeichnen braucht und sind nicht auf externe Aufrufe wie glColor<br />
angewiesen - der Treiber stellt aus diesen Displaylisten beim GL_COMPILE-Vorgang<br />
ein statisches Vertex Buffer Object her, welches extrem effizient von der<br />
Grafikkarte bearbeitet werden kann. Der Treiber erhält alle Daten "am Stück" und<br />
kann sich 100%ig auf das Rendern "konzentrieren", weil der Benutzer gar nicht<br />
die Möglichkeit erhält, irgendetwas absurdes zu tun.<br />
<br />
Will man diese Art von Displaylisten ohne Shader für die Selektion fit machen,<br />
benötigt man auf der einen Seite Listen mit den "normalen Farben" (welche auch<br />
schlichtweg "keine Farben" sein können, wenn nur Texturen verwendet werden) und<br />
Listen mit eingebauten Selektionsfarben.<br />
Bei dieser Methode wird die benötigte Geometrie <i>verdoppelt</i> - mit anderen<br />
Worten: Sie kommt aus Speichersicht überhaupt nicht in Frage.<br />
<br />
Es muss also ein Weg gefunden werden, der folgende Kriterien erfüllt:<br />
1) Der Treiber muss seine Daten "am Stück" erhalten können.<br />
2) Selektion und normales Rendering sollen die gleiche Geometrie nutzen.<br />
3) Trotzdem müssen die Farben austauschbar sein.<br />
<br />
Die Lösung sieht so aus, dass wir selbst ein Vertex Array (Hauptspeicherbasiert)<br />
oder ein Vertex Buffer Object (VRAM-Basiert) erstellen. Der Einfachheit halber<br />
stelle ich hier nur die Variante mit den VAs vor - es sollte sich aber ziemlich<br />
gut auf VBOs übertragen lassen.<br />
<br />
Es werden drei Arrays erstellt:<br />
- Vertices<br />
- Farbdaten oder Texturkoordinaten<br />
- Selektionsfarben<br />
<br />
In OpenGL ist es nun möglich, mittels der gl*Pointer-Funktionen die Datenquellen<br />
für einen Aufruf von glDrawArrays zu bestimmten. glVertexPointer zeigt stets auf<br />
unsere Vertices.<br />
<br />
glColorPointer wird je nach dem, ob es sich um eine Selektion oder ein normales<br />
Rendering handelt, auf die Farbdaten oder die Selektionsfarben gesetzt. Werden<br />
nur Texturen verwendet, bleibt glTexCoordPointer immer auf diese gesetzt,<br />
der Farbpointer immer auf die Selektionsfarben - und je nach Fall werden dann<br />
GL_COLOR_ARRAY oder GL_TEXTURE_2D deaktiviert oder aktiviert.<br />
<br />
<br />
==Schlusswort==<br />
<br />
Das war jetzt Color Picking. Ich sage es aber gerne nochmal: Bevor ihr euch<br />
meine Implementation auf's Auge drücken lasst denkt daran, dass es nur eine<br />
Lösung von vielen ist.<br />
Wann immer in eurer Situation etwas anderes angebracht sein sollte - macht es<br />
anders!<br />
Es kann auch nicht schaden, wenn ihr euch den kompletten Beispielcode zum<br />
Tutorial (gibt es [http://home.arcor.de/m3ep/tutorial/Selektion-Colorpicking.7z hier] zum Herunterladen) mal anseht. Neben dglOpenGL und<br />
Jedi-SDL verwende ich noch 3 Units, die von mir sind. Ich erhebe keinen<br />
Urheberrechtsanspruch auf diese Units, d.h. ihr könnt sie nach belieben<br />
ausschlachten, verändern und selbst verwenden (meinetwegen auch kommerziell).<br />
<br />
Wenn ihr eine Frage oder Feedback zum Tutorial oder zum Verfahren habt, findet<br />
ihr mich öfters im IRC-Channel von DGL oder erreicht mich bei Fragen von<br />
öffentlichem Interesse auch im [http://delphigl.com/forum/index.php Forum].<br />
<br />
Gruß Waran<br />
[[Kategorie:Tutorial|ColorPicking]]</div>Waranhttps://wiki.delphigl.com/index.php?title=Tutorial&diff=23970Tutorial2009-08-02T15:56:04Z<p>Waran: /* Grundlagen-Tutorials */</p>
<hr />
<div>Auf dieser Seite findet ihr alle Tutorials die DelphiGL.com zu bieten hat. Falls ihr zu einem Thema kein Tutorial findet könnt ihr noch einen Blick auf die [[Techniken und Algorithmen]] werfen. Diese enthalten weitere Artikel zu bestimmten Techniken.<br />
<br />
=Hinweise=<br />
Bitte tragt selbst '''keine''' eigenen Tutorials ohne Absprache mit [[Benutzer:Flash (Kevin Fleischer)|Flash]] bzw. [[Benutzer:Phobeus|Phobeus]] hier ein. Tutorials werden prinzipiell vom DGL-Team gegengelesen, ''bevor'' sie veröffentlicht werden.<br />
<br />
Wer mit dem Gedanken spielt, ein Tutorial für DGL zu schreiben, sollte sich bereits bei der Themenwahl mit dem DGL-Team absprechen. DGL ist sehr an neuen Tutorials interessiert. Nur sollte man beachten, dass nichts doppelt geschrieben wird, bzw. dass nicht 2 Mann zur selben Zeit das selbe Thema beackern.<br />
<br />
==Hinweis für alle Programmieranfänger==<br />
Falls ihr OpenGL nutzen wollt aber noch keinerlei Programmiererfahrung habt, so solltet ihr zuerst eine Programmiersprache lernen.<br />
<br />
DGL kann folgende Tutorials empfehlen:<br />
<br />
{|{{Prettytable_B1}} width="100%"<br />
!Link<br />
!Sprache<br />
!Beschreibung<br />
|-<br />
|[http://www.delphi-treff.de/tutorials/ Delphitutorials bei www.delphi-treff.de]<br />
|{{Deutsch}}<br />
|Delphi Source der Delphi Treff entstand durch den Zusammenschluss von Delphi-Source und dem Delphi-Treff und wurde mittlerweile wieder in Delphi-Treff umbenannt. Diese Community verfügt über eine ausgezeichnete Sammlung von Tutorials zum Thema "Delphiprogrammierung". Es werden nicht nur die Grundlagen erklärt sondern nahezu alle Bereiche der Programmierung mit Delphi. Außerdem verfügt diese Community über ein Forum welches mit seiner ''Bastelecke'' auch für Anfänger geeignet ist.<br />
|-<br />
|[http://crashkurs.christian-stelzmann.de/ Crashkurs von Christian Stelzmann]<br />
|{{Deutsch}}<br />
|Der Crashkurs von Christian erklärt neben den Grundlagen zur und über die Sprache auch die IDE anhand von zahlreichen einfachen Beispielen, die den Einstieg in Delphi stark vereinfachen und so eine einfache Einführung in die Arbeit mit Delphi bieten.<br />
|-<br />
|}<br />
<br />
''Wer sehen möchte was DGLer aus dem hier Gelernten und ihrer Kreativität so machen, findet Beispiele davon in der [[DGL_Projekte]]-Ecke.''<br />
<br />
=Tutorials=<br />
{{Hinweis|Alle Tutorials sind der [[:Kategorie:Tutorial]] zugeordnet.}}<br />
<br />
<div align="center"><br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Schwierigkeitsgrad<br />
!Bedeutung<br />
|-<br />
|{{Level_1}} <br />
|Jeder Schritt wird ausführlich erklärt. Absolut Einsteigertauglich.<br />
|-<br />
|{{Level_2}} <br />
|Verständnis der Grundprinzipien wird vorraus gesetzt. Die Materie bleibt aber einfach.<br />
|-<br />
|{{Level_3}}<br />
|Ihr wisst um was es geht. Es wird erwartet, dass ihr selbst das Thema weiterdenkt.<br />
|-<br />
|{{Level_4}} <br />
|Das Tutorial bietet euch einen Einstieg. Es wird erwartet, dass ihr euch selbst noch eingehender mit den beschriebenen Techniken befasst. Für Fragen steht unser Forum zur Verfügung.<br />
|-<br />
|{{Level_5}} <br />
|Um das Tutorial zu verstehen werden Kenntnisse auf dem entsprechenden Gebiet vorrausgesetzt, welche über Grundwissen hinausgehen. Es wird erwartet, dass ihr euch eingehender mit dem Thema auseinandersetzt und auch andere Quellen lest/gelesen habt. Für Fragen steht unser Forum zur Verfügung.<br />
|}<br />
</div><br />
<br />
== Einsteiger-Tutorials ==<br />
<div align="center"><br />
{{Hinweis|Die Einsteiger-Tutorials wurden auf [[SDL]] umgestellt. Dadurch wurde das Laden von Texturen erleichtert, vor allem aber ermöglicht SDL plattformunabhängig zu programmieren. Ihr benötigt deshalb die ''SDL.pas''. Diese Datei und alle anderen benötigten Dateien findet ihr im '''[[DGLSDK]]'''}}<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Quickstart]] (VCL)<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Lektion1.gif|right]] "Quickstart: OpenGL & Delphi"<br> <br />
Für alle, die einen schnellen Einstieg in die OpenGL Programmierung mit Delphi suchen, hat Flash hier einen Einstieg geschaffen. Neben dem erstellen eines eigenen OpenGL-Templates hat er für alle, die Großes mit OpenGL vorhaben, am Ende noch einige Hinweise bereitgestellt.<br />
<br />
''In diesem Tutorial wird eine Codevorlage für OpenGL-Projekte geschaffen. Diese basiert allerdings auf Borlands Visual Component Library (VCL) und nicht auf SDL. '''Unabhängig davon beherbergt dieses Tutorial im 2. Teil einige allgemeingültige Hinweise für OpenGL-Anfänger.''' Wer nicht mit SDL arbeitet weil z.B. Plattformunabhängigkeit nicht gewünscht oder durch die Sprache bereits gegeben ist, kann diese Codebasis leicht auf seine Sprache übertragen.''<br />
|-<br />
![[Tutorial Lektion 1]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Lektion1.gif|right]] "Nicht zu weit aus dem Fenster lehnen"<br> <br />
Dieses Tutorial von Magellan ist für alle Neueinsteiger gedacht. Hier werden Grundlagen von "Was ist OpenGL" bis zu "Wie initialisiere ich OpenGL?" besprochen.<br />
|-<br />
![[Tutorial Lektion 2]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Lektion2.jpg|right]] "Entdeckung einer neuen Welt"<br> <br />
Unter dieser Überschrift empängt euch Phobeus zu eurem ersten OpenGL Tutorial welches sich mit der Anwendung der OpenGL-API befasst.<br />
|-<br />
![[Tutorial Lektion 3]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Lektion3.gif|right]] "Eine Welt des Grauens?"<br> <br />
Hinter diesem Titel verbirgt sich ein Einsteigertutorial zum Thema Matrizen in OpenGL. Wiederum führt euch Phobeus durch den Stoff.<br />
|-<br />
![[Tutorial Lektion 4]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Lektion4.png|right]] "Texturen, Tapeten und Ihre Tücken"<br> <br />
Wie bekomme ich ein Bild auf meine Primitiven? Wer sich diese Frage bei den vorigen Tutorials gestellt hat, der bekommt hier nun von Phobeus die Antworten.<br />
|-<br />
![[Tutorial Lektion 5]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Lektion5.jpg|right]] "Artenvielfalten und Ihre Folgen"<br> <br />
In diesem Tutorial geht Phobeus auf weitere Zeichentechniken und Methoden zur Verbesserung der Performance unter OpenGL ein.<br />
|-<br />
!''Tutorial Lektion 6 ''<br />
|[[Bild:Tutorial_na.jpg|right]] "Dark Engine"<br> <br />
Dieses Tutorial wurde geplant aber niemals umgesetzt. Heute hätte es auch keine Relevanz mehr, da die Dark Engine nicht gepflegt wurde. Falls ihr ein gutes Einsteigertutorial als Ersatz vorschlagen wollt, könnt ihr dies im Feedback-Forum von DelphiGL.com tun.<br />
|-<br />
![[Tutorial Lektion 7]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Lektion7.png|right]] "Verblendet!"<br> <br />
Wenn man halbdurchsichtige Fensterscheiben, Lightmaps oder etwas ähnliches in sein Projekt einbauen will, dann kommt man um Blending nicht herum. Wie man das ganze Nutzen kann ist in diesem Tutorial von Phobeus erklärt.<br />
|-<br />
![[Tutorial Lektion 8]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Lektion8.gif|right]] "Das Wesen von hell und dunkel - Licht"<br> <br />
Ohne Beleuchtung sieht selbst jede 3D-Umgebung platt aus. In diesem Tutorial wird primär der richtige Gebrauch des OpenGL-Lichtes beschrieben. Darüberhinaus wird noch die Berechnung von Normalen erklärt.<br />
|-<br />
![[Tutorial 2D]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_2D.jpg|right]] "2D mit OpenGL"<br> <br />
OpenGL ist zwar primär eine 3D-API, eignet sich aber, nicht zuletzt dank seiner leistungsstarken Hardwarebeschleunigung und der damit verbundenen Features, auch sehr gut für reine 2D-Anwendungen. Dieses Tutorial von Sascha Willems geht sehr ausführlich auf die Nutzung von OpenGL für 2D-Anwendungen ein.<br />
|-<br />
![[Tutorial Matrix2]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Matrix2.png|right]] "Matrix2 - Matrizen und Matrixmanipulationen"<br> <br />
Das Thema Matrizen stellt OpenGL-Einsteiger regelmäßig vor "unlösbare" Aufgaben:<br><br />
''Wieso dreht sich der Würfel so komisch, und nicht um sich selbst?''<br> <br />
''Wieso verschiebt OpenGL die Kugel denn dahin, und nicht dorthin?''<br><br />
Dieses Tutorial von Flash befasst sich mit den 3 Matrixtypen, die es in OpenGL gibt und erklärt was die Befehle '''glScale, glRotate und glTranslate''' wirklich machen.<br />
|-<br />
|}<br />
</div><br />
<br />
== Grundlagen-Tutorials ==<br />
<div align="center"><br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Abseits eckiger Welten]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Abseits_eckiger_Welten.gif|right]] "Abseits eckiger Welten"<br> <br />
3D-Welten bestehen seit eh und je aus Dreiecken, was sie oft recht eckig erscheinen lässt. In diesem Tutorial lernt ihr allerdings wie man mit Hilfe von Evaluatoren in OpenGL auch Rundungen erzeugen kann.<br />
|-<br />
![[Tutorial Renderpass]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Renderpass.jpg|right]] "Renderpass - Die Welt daneben"<br> <br />
OpenGL bietet nicht nur die Möglichkeit seine Szene direkt auf den Bildschirm zu rendern, sondern auch diese in eine Textur zu rendern um diese dann auf ein Objekt zu kleben. Dadurch ergeben sich diverse neue Möglichkeiten, wie z.B. Spiegel, Portale oder nachträgliche Manipulation der Textur. Wie ihr eure Szene in eine Textur bekommt, erfahrt ihr hier.<br />
|-<br />
![[Tutorial Selection]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Selection.gif|right]] "Objectselektion A"<br> <br />
Die Selektion von Objekten braucht man spätestens dann, wenn man ein komfortable Interaktion mit der Spielwelt erstellen will. Mit diesem Tutorial von DCW_MrT ist die Thematik kein Problem mehr.<br />
|-<br />
! [[Tutorial Objektselektion]]<br />
{{Level_2}} <br />
| [[Bild:Tutorial_Selection_tut03.jpg|right]] "Objektselektion B" <br><br />
Wie simpel der Objektselektionsmodus von OpenGL zu benutzen ist, wird in diesem Tutorial von Sascha Willems vermittelt. Dazu gibt es den Source-Code und eine fertig kompilierte Anwendung.<br />
|-<br />
! [[Tutorial ColorPicking]]<br />
{{Level_2}} <br />
| [[Bild:Tutorial_ColorPicking_Screenie.png|right]] "Objektselektion mit Color Picking" <br><br />
Eine zukunftssichere und vor allem nVidia-Kompatible Lösung für das Selektionsproblem. Verwendet Shader und richtet sich eher an erfahrenere Leser, die eine Methode suchen, die sie so auch in größeren Projekten einsetzen könnten.<br />
|-<br />
![[Tutorial TexFilter]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_TexFilter.jpg|right]] "Texturfilterung - Texturen-Feintuning"<br> <br />
Texturen sind seit langem ein wichtiger Bestandteil im Bereich der Echtzeitgrafik. OpenGL bietet auf diesem Gebiet auch diverse Möglichkeiten Texturen auch filtern zu lassen. Welche das sind und wie sie sich auswirken, könnt ihr in diesem Tutorial von Delphic nachlesen.<br />
|-<br />
![[Tutorial Kamera1]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Kamera1.gif|right]] "Dreht sich das Universum um uns? und andere philosophische Fragen"<br> <br />
In diesem Tutorial von Delphic geht es um die Kamera. Wie eine Kameraklasse gebaut sein könnte und was sie macht wird hier erklärt.<br />
|-<br />
|}<br />
</div><br />
<br />
== Effekte ==<br />
<div align="center"><br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Nebel]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Nebel.jpg|right]] "DGL Fogging Tutorial".<br> <br />
Erstaunlich einfach lässt sich mit OpenGL Nebel darstellen. Wie einfach, zeigt euch Lithander in diesem Tutorial. <br />
|-<br />
![[Tutorial Partikel1]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Partikel1.gif|right]] "Partikel-Tutorial I".<br><br />
Eine Partikel-Engine sollte in (fast) jeder Engine enthalten sein. Anhand dieses Tutorials von Lithander könnt ihr den Grundstein dazu legen.<br />
|-<br />
![[Tutorial BumpMap]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_BumpMap.png|right]] "Bumpmapping - Plastisches 2D".<br> <br />
Bumpmapping ist eine immer stärker genutzte Technik, um polygonarme Oberflächen ohne Tesselation mit vorgegaukelten Details - abhängig vom Lichteinfall - zu versehen. In diesem Tutorial zeigt euch HomerS, wie man Bumpmapping über die NVIDIA-spezifischen Combiner realisiert.<br />
|-<br />
![[Tutorial MultiTexturing]]<br />
{{Level_2}} <br />
|[[Bild:Multitex05.jpg|right]] "Multitexturing".<br><br />
Wie man mehrere Texturen auf ein Polygon bringen kann, erklärt auch Sascha Willems in diesem Tutorial zum Thema Multitexturing. Multitexturing ist seit OpenGL1.3 Teil des GL-Kerns und kann für z.B. für Lightmapping bzw. Detailmapping verwendet werden.<br />
|-<br />
![[Tutorial StencilSpiegel]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_StencilSpiegel.jpg|right]] "Spiegelungen mit dem Stencil-Buffer".<br> <br />
Eine Echtzeit-Spiegelung ist einer der schönsten Effekte einer 3D-Welt und trägt viel zum Realismus bei. Eine Möglichkeit Spiegelungen über den Stencilpuffer zu realisieren, wird in diesem Tutorial von Sascha Willems erklärt.<br />
|-<br />
![[Tutorial StereoSehen]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_StereoSehen.gif|right]]Auch wenn moderne Grafikkarten durch eine immer besser werdende Darstellung dem Benutzer versuchen das Betreten einer virtuellen 3D-Welt vorzugaukeln, so schafft es doch auch das beste Doom3-Monster nur bis zur Glasröhre zu erschrecken, rutscht dann aber quietschend davon ab. Was also tun, wenn man einen Schritt weiter gehen und dem Anwender wirkliches 3D bieten möchte? Wer eine 3D-Brille hat, wird mit diesem Tutorial von Delphic eine Möglichkeit finden, die dritte Dimension am Computer zur erschließen.<br />
|-<br />
![[Tutorial Alphamasking]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Alphamasking_tut04.jpg|right]]In diesem kleinen aber feinen Tutorial erklärt Sascha Willems, wie man Alphamasking dazu verwenden kann, eine Szene optisch aufzuwerten und gleichzeitig Performance zu sparen.<br />
|-<br />
![[Tutorial Wassereffekt]]<br />
{{Level_2}} <br />
|[[Bild:Wassertutorial-scrshot-preview.jpg|right]]In diesem Tutorial erklärt Lord Horazont wie man eine Wasserebene mit Brechungen mit und ohne Shader erzeugen kann.<br />
|-<br />
|}<br />
</div><br />
<br />
==Extensions==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Cubemap]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_Cubemap_mini.jpg|right]] "GL_ARB_Texture_Cubemap".<br> <br />
In diesem Tutorial erklärt Sascha Willems die Grundfunktionen der '''GL_ARB_Texture_Cubemap'''-Extension und zeigt auch weiterführende Techniken auf.<br />
|-<br />
![[Tutorial Vertexbufferobject]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial Vertexbufferobject preview.jpg|right]] "GL_ARB_Vertex_Buffer_Object".<br> <br />
Diese Extension führte '''VBO'''s ein. Wie man mit damit Vertexdaten schnell im Grafikkarten- und Hauptspeicher ablegt und darauf zugreift, erklärt Sascha Willems in diesem Tutorial.<br />
|-<br />
![[Tutorial Vertexprogramme]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_VP_preview.jpg|right]] "GL_ARB_Vertex_Program".<br> <br />
In diesem umfangreichen Tutorial werden alle wichtigen Bereiche der Programmierung mit der GL_ARB_Vertex_Program-Extension abgedeckt. Man kann es als umfassende deutsche Referenz zu diesem Thema sehen, da auch alle wichtigen Funktionen aufgelistet werden und es auch sonst an nichts fehlt.<br />
|-<br />
![[Tutorial NVOcclusionQuery]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_NVO_preview.jpg|right]] "NV_Occlusion_Query".<br> <br />
Lard Middendorf geht in diesem Tutorial auf die Verwendung der NV_Occlusion_Query-Extension ein.<br />
|-<br />
![[Tutorial Pixelbuffer]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_Pixelbuffer_preview.jpg|right]] "WGL_ARB_Pixel_Buffer".<br> <br />
Sascha Willems erklärt hier leicht verständlich den Umgang mit der Pixelbuffer-Extension. Als Additum wird auch noch auf die Nutzung dieser Extension für Shadowmapping eingegangen.<br />
|-<br />
![[Tutorial_Framebufferobject]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_Framebufferobject_Preview.jpg|right]] "GL_EXT_FRAMEBUFFER_OBJECT".<br> <br />
Deathball erklärt in diesem Tutorial wie man Framebufferobjekte erstellt und diese zum Offscreenrendern benutzt.<br />
|-<br />
|}<br />
<br />
== Shader ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial glsl|Tutorial glSlang]]<br />
{{Level_4}} <br />
|[[Bild:Tutorial_glsl1.png|right]] "Einführung in GLSL".<br> <br />
Nach langem Ringen und Handeln hat es das ARB letztendlich doch geschafft, eine einheitliche Shaderhochsprache für OpenGL zu veröffentlichen, nämlich ''glSlang''. Mit glSlang können nun auch unter OpenGL Vertex- und Fragment-Shader in einer lesbaren, C-ähnlichen Hochsprache geschrieben werden, was deren Entwicklung stark vereinfacht. Diese Einführung von Sascha Willems ist weniger ein Tutorial, als ein kompletter Überblick über glSlang. Hier erfährt der Leser nicht nur etwas über die Benutzung von Shadern im Programm, sondern auch alles über die Sprachelemente, inklusive diverser Beispiele.<br />
|-<br />
![[Tutorial glsl2|Tutorial glSlang 2]]<br />
{{Level_4}} <br />
|[[Bild:Tutorial_na.jpg|right]] "GLSL-Ergänzungen und Beispiele".<br> <br />
Dieses Tutorial von La_Boda ist eine direkte Fortsetzung des GLSL-Tutorials. Es behandelt verstärkt die Praxis und liefert anhand von einigen Beispielen eine bessere Sicht auf die bereits gelernte Theorie.<br />
|-<br />
|}<br />
<br />
== KI ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial pathfinding|Tutorial Pathfinding]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_pathfinding.png|right]] "Pathfinding 1".<br> <br />
In diesem Tutorial zeigt euch Flo wie man recht simpel eine Wegfindungsroutine implementiert. Besonders wenn man sowas ohne großen Lernaufwand in sein Spiel einbinden möchte, sollte man einen Blick riskieren.<br />
|-<br />
![[Tutorial pathfinding2|Tutorial Pathfinding 2]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_pathfinding2.png|right]] "Pathfinding 2".<br> <br />
Gerade bei aktuelleren Programmen reicht es meist nicht aus, wenn man seine Einheiten nur in 8 Himmelsrichtungen bewegen kann. Frase stellt in diesem Tutorial vor, wie man eine Wegfindungsroutine implementieren kann, wie diese in einem heutigen RTS vorkommen kann.<br />
|-<br />
|}<br />
<br />
== Terrain und Landschaften ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Terrain1]]<br />
{{Level_4}} <br />
|[[Bild:Tutorial_Terrain1.gif|right]] "Aussenlandschaften mit System - Heightmaps".<br> <br />
Anhand der Graustufenwerte einer Bitmap-Datei kann man relativ einfach eine imposante Landschaft erstellen. Wie das ganze funktioniert erklärt euch Delphic in diesem Tutorial. Außerdem wird noch die Implementation von Skyboxen erklärt.<br />
|-<br />
![[Tutorial Terrain2|Tutorial Terrain 2]]<br />
{{Level_4}} <br />
|[[Bild:Tutorial_Terrain2.gif|right]] "Heightmap-Texturen".<br> <br />
Da das Terrain aus dem vorigen Tutorial noch recht eintönig grau aussieht und das natürlich geändert werden soll, erklärt euch Delphic, wie man schmucke Schatten und Texturen für die Heightmap generieren kann.<br />
|-<br />
![[Tutorial Terrain3|Tutorial Terrain 3]]<br />
{{Level_5}} <br />
|[[Bild:Tutorial_Terrain3.gif|right]] "Terrain im Detail".<br> <br />
Da größere Landschaften aufgrund der hohen Polygonanzahl sehr aufwändig zu rendern sind erklärt euch Delphic hier, wie man entfernte Dreiecke "zusammenlegen" kann, um Rechenleistung zu sparen.<br />
|-<br />
![[Tutorial Skyboxen]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Skybox_Vorschau.jpg|right]] "Skyboxen".<br> <br />
In diesem Tutorial erklärt Sascha Willems kurz und bündig den Umgang mit Skyboxen, mit denen man Landschaften schnell sehr stark optisch aufwerten kann. Es wird sowohl auf die Erstellung der Skybox-Texturen mit dem Programm Terragen als auch die Implementation der Skybox in OpenGL eingegangen.<br />
|-<br />
|}<br />
<br />
== Spieletutorials und Softwareentwicklung==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Bomberman1|Tutorial Bomberman 1]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_Bomberman1.jpg|right]] "Bomberman1 - Codebasis und Editor".<br> <br />
Im ersten Teil dieser kleinen Tutorialserie zum Thema Spieleprogrammierung kümmern wir uns neben der Erstellung unseres Basiscodes auch um einen fertigen Editor. Nach der Durcharbeitung dieses Tutorials von Sascha Willems sollte der Leser alle Grundprinzipien zur Programmierung eines Spiels verstanden haben.<br />
|-<br />
![[Tutorial Bomberman2|Tutorial Bomberman 2]]<br />
{{Level_3}}<br />
|[[Bild:Tutorial_Bomberman2.jpg|right]] "Bomberman2 - Der 3D-Bombermanklon (Grundversion)".<br> <br />
Im zweiten Teil gehts ans Eingemachte, nämlich einen fertigen Bombermanklon. In Sascha Willems Tutorial werdet ihr zusätzlich zu den bereits erworbenen Prinzipien diverse Techniken die in so ziemlich jedem Spiel Verwendung finden erlernen.<br />
|-<br />
![[Tutorial Softwareentwicklung1|Tutorial Softwareentwicklung 1]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_SWE1.jpg|right]] "Softwareentwicklung1 - Objektorientierte Softwareentwicklung mit UML".<br> <br />
Im ersten Teil dieser Tutorialserie zum Thema Softwareentwicklung erklärt euch Flash, wie man an ein Projekt herangeht und herausfindet was eigentlich zu tun ist. Es geht dabei um Analyse der Anforderungen und die Modellierung sogenannter Use Cases. Die hier vorgestellten Arbeiten sind Grundlage um später Klassen zu finden auf denen dann der Code aufgebaut wird.<br />
|-<br />
![[Tutorial Softwareentwicklung2|Tutorial Softwareentwicklung 2]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_SWE2.jpg|right]] "Softwareentwicklung2 - Objektorientierte Softwareentwicklung mit UML".<br> <br />
Im zweiten und umfangreichsten Teil der Serie steht das Thema "Klassen" im Zentrum. Flash erklärt euch wie man aus den Use Cases Klassen ableitet und welche unterschiedlichen Einsatzgebiete Klassen innerhalb der Software haben können.<br />
|-<br />
![[Tutorial Softwareentwicklung3|Tutorial Softwareentwicklung 3]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_SWE3_Interface.jpg|right|128px]] "Softwareentwicklung3 - Objektorientierte Softwareentwicklung mit UML".<br> <br />
Im letzten Teil der Serie steht das Thema "Verhalten" im Zentrum. Flash erklärt euch wie die Klassen miteinander in Beziehung gesetzt werden. Außerdem wird nocheinmal auf den RUP als '''iterative''' Vorgehensweise eingegangen.<br />
|-<br />
|}<br />
<br />
== Mathematisches ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Lineare Algebra]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_lineare_Algebra_Preview.jpg|right]] "Vektorrechnung".<br> <br />
In vielen Tutorials tauchen eine Menge Begriffe aus der linearen Algebra und analytischen Geometrie auf. Wer bei Begriffen wie Vektoren, Skalar-Produkt, Vektorkreuzprodukt, etc. ein wenig Auffrischung und Implementationshinweise braucht, ist mit diesem Tutorial von EternalLearner an der richtigen Stelle.<br />
|-<br />
![[Tutorial Nachsitzen]]{{Level_1}} <br />
|[[Bild:Tutorial_Nachsitzen_preview.png|right]] "3d-Mathematik".<br> <br />
Wer die mathematischen Grundlagen wie Sinus, Cosinus und Matrizen aus der Schule schon wieder vergessen oder noch vor sich liegen hat, der kann mit Hilfe dieses Tutorials von Delphic dieses Wissen erlernen bzw. auffrischen.<br />
|-<br />
![[Tutorial Objekt gedreht und dennoch nach vorne bewegt]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Objekt_gedreht_und_dennoch_nach_vorne_bewegt_preview.gif|right]] "Objekt gedreht und dennoch nach vorne bewegt".<br> <br />
SchodMC erklärt in diesem Tutorial wie man ein Objekt drehen und dabei trotzdem vorwärts bewegen kann. Quer fahrende Autos sind zwar praktisch zum Einparken Aber doch eher selten ;-)<br />
|-<br />
![[Tutorial Objekt immer um eigene Achse drehen]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Objekt_immer_um_die_eigene_Achse_drehen_preview.gif|right]] "Objekt immer um eigene Achse drehen".<br><br />
Wenn ihr euer Objekt nun noch um die eigene Achse drehen wollt, seid ihr mit diesem Tutorial von SchodMC an der richtigen Adresse<br />
|-<br />
![[Tutorial Separating Axis Theorem]]<br />
{{Level_2}} <br />
|[[Bild:SAT_Kollision.jpg|right|128px]] "Separating Axis Theorem"<br><br />
Seth erklärt in diesem Tutorial wie man Polygonkollisionen mit Hilfe des ''Seperating Axis Theorem'' erkennen kann. <br />
|-<br />
![[Tutorial Kollision1]]<br />
{{Level_1}} <br />
|[[Bild:Tutorial_Kollision1_Coll2.png|128px|right]] "Kollision 1"<br><br />
Reinhard Niehoff fragte uns ob er ein Tutorial über Kollision schreiben könnte. Das konnten wir nicht ablehnen, und so entstand dieses Tutorial in dem grundlegende Kollisionsberechnungen erklärt werden. Weitere sollen folgen. <br />
|-<br />
![[Tutorial Kollision2]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Kollision2_Thumb.png|128px|right]] "Kollision 2"<br><br />
Beim zweiten Tutorial gehts mehr in die Tiefe und einige Spezialfälle bei Kugel-Polygon-Kollisionen werden erläutert. Mit dabei: Die [[Werkzeugkiste]] mit nützlichen Funktionen.<br />
|-<br />
![[Tutorial Kollision3]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_Kollision3_Thumb.png|128px|right]] "Kollision 3"<br><br />
Beim letzten Tutorial dieser Serie gehts darum, wie man die bisherigen Ansätze in einem Programm unterbringt.<br />
|-<br />
|}<br />
<br />
== Grafik und Modellierung ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Modellierung eines Low-Poly Menschen Teil 1]]<br />
{{Level_4}} <br />
|[[Bild:Tutorial_Low-Poly-Mensch1_preview.jpg|right]] "Modellierung eines Low-Poly-Menschen".<br> <br />
Die Modellierung von organischen "Objekten" gehört mit zu den kompliziertesten Aufgaben, die es beim Modelling gibt. Wie man einen Menschen mit aus möglichst wenigen Polygonen mit dem Programm 3D Studio Max erstellen kann wird in diesem Tutorial von Sascha Willems erklärt.<br />
|-<br />
![[Tutorial Modellierung eines Low-Poly Menschen Teil 2]]<br />
{{Level_4}} <br />
|[[Bild:Tutorial_Low-Poly-Mensch2_preview.jpg|right]] "Kleider machen Leute (UVW-Mapping)".<br> <br />
Nun spendiert Sascha Willems seinem Menschen aus dem 1. Tutorial eine schmucke Uniform, so dass er sich endlich in der Öffentlichkeit blicken lassen kann.<br />
|-<br />
|}<br />
<br />
== Skripte ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial Scripting mit JvInterpreterProgram]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_JvInterpreter_preview.png|right]] "Skripting mithilfe der Jedi-Code-Library".<br> <br />
SchodMC erklärt hier wie man mit relativ wenig Aufwand Skripte in eigene Programme integrieren kann.<br />
|-<br />
![[Tutorial Scriptsprachen Teil 1]]<br />
{{Level_5}} <br />
|[[Bild:Tutorial_Skriptsprachen1_preview.gif|right]] "Scriptsprachen Teil 1 - Einführung".<br> <br />
Für alle die schon immer einmal wissen wollten wie ein Compiler arbeitet ist diese Tutorial-Reihe von Delphic genau das richtige.<br />
<br />
Der erste Teil widmet sich der Lexikalischen Analyse und dem Parsen des Quellcodes<br />
|-<br />
![[Tutorial Scriptsprachen Teil 2]]<br />
{{Level_5}} <br />
|[[Bild:Tutorial_Skriptsprachen2_preview.gif|right]] "Scriptsprachen Teil 2 - Virtuelle Computer und Code Erzeugung".<br><br />
Für alle die schon immer einmal wissen wollten wie ein Compiler arbeitet ist diese Tutorial-Reihe von Delphic genau das richtige.<br />
<br />
Der zweite Teil beschreibt den Bau einer VM und der Codeerzeugung<br />
|-<br />
|}<br />
<br />
== Delphi allgemein ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
! [[Tutorial Debugging]]<br />
{{Level_2}} <br />
| [[Bild:Tutorial Debugging.gif|right]] "Debugger benutzen und andere praktische Tipps" <br><br />
In diesem Tutorial werdet von Delphic mit der Nutzung des Delphi-Debuggers eingeführt. Auch werden Wege zur Vermeidung von Fehlern aufgezeigt. Genauso findet Ihr aber auch in diesem Tutorial Hinweise, zu häufig begangenen Fehlern und deren Ursachen.<br />
|-<br />
! [[Tutorial Komponentenentwicklung]]<br />
{{Level_2}} <br />
| [[Bild:Tutorial Komponentenentwicklung.png|right]] "Komponentenentwicklung" <br><br />
In diesem Tutorial werdet ihr ein wenig tiefer in die Entwicklung von Komponenten unter Delphi eingeführt. Es wird Grundwissen auf diesem Gebiet vorausgesetzt.<br />
|-<br />
![[Tutorial Multithreading]]<br />
{{Level_3}} <br />
|[[Bild:Tutorial_Multithreading.gif|right]] "Das Prinzip der Dualität".<br> <br />
Threads sind ein erweitertes Prinzip des bekannten Multitasking und werden innerhalb eines Programmes oft dazu genutzt, verschiedene Aufträge gleichzeitig abzuarbeiten. LossyEx erklärt euch hier deren Nutzung.<br />
|-<br />
! [[Tutorial Software-Synthesizer]]<br />
{{Level_4}} <br />
| [[Bild:Noexist.jpg|right]] "Software-Synthesizer" <br><br />
Computerspiele bestehen nicht nur aus Grafik. Dieses Tutorial widmet sich einem ganz anderen Bereich der Spieleprogrammierung: Der Erzeugung von synthetischen Sounds und Musik.<br />
|}<br />
<br />
<br />
== SDL ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
![[Tutorial SDL Einstieg]]<br />
{{Level_2}} <br />
|[[Bild:Tutorial_Lektion1.gif|right]] "SDL-Einsteiger-Tutorial"<br> <br />
Crossplattform-Programmierung ist das Zauberwort, welches in den letzten Jahren - dank verstärkter Präsenz von Linux - immer wieder in den Programmierforen des Internets auftaucht. Für Grafikprogrammier ist [[SDL]] hier das Mittel der Wahl. Bekannte Titel wie "Quake III" und "Civilisation - Call to Power" bauen bereits auf diese Bibiothek für ihre Linux-Ports. Phobeus zeigt euch in diesem ersten SDL-Tutorial was SDL ist und wie man es benutzt.<br />
|-<br />
![[Tutorial SDL_RWops]]<br />
{{Level_2}}<br />
| [[Bild:Noexist.jpg|right]] "SDL_RWops-Tutorial"<br><br />
SDL benutzt für den Dateizugriff SDL_RWops. [[Benutzer:Lord Horazont|Lord Horazont]] zeigt euch in diesen Tutorial wie man diese benutzt und auch komfortabler gestaltet.<br />
|}<br />
<br />
== Rendertechniken ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
! [[Tutorial Octree]]<br />
{{Level_1}} <br />
| [[Bild:Tutorial Octree preview.jpg|right]] "Octrees" <br><br />
Octrees sind eine einfach zu implementierende, aber sehr effiziente Möglichkeit um besonders Outdoor-Szenen abhängig vom Betrachterblickfeld stark zu beschleunigen. In diesem Tutorial zeigt Shadow euch eine komplette Implementation eines Octrees inklusive ausgiebigem Quellcode.<br />
|-<br />
! [[Tutorial Frustum Culling]]<br />
{{Level_1}} <br />
| [[Bild:Tutorial Frustum Culling.jpg|right]] "Frustum Culling" <br><br />
Frustum Culling ist eine einfache Möglichkeit die Rendergeschwindigkeit zu erhöhen, da man damit schon vor dem Senden der Daten an die Grafikkarten feststellen kann, welche Objekte sich im Blickfeld des Spielers befinden und welche nicht.<br />
|}<br />
<br />
== Raytracing ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
! [[Tutorial Raytracing - Grundlagen I]]<br />
{{Level_4}} <br />
| [[Bild:Tutorial_RaytracingI_thumb.jpg|right]] "Raytracing - Grundlagen I" <br><br />
Die Grundzüge des Raytracings Teil 1 - Von den Strahlen bis zur ersten Darstellung von Kugeln und Ebenen<br />
|-<br />
! [[Tutorial Raytracing - Grundlagen II]]<br />
{{Level_4}} <br />
| [[Bild:Tutorial_RaytracingI_thumb.jpg|right]] "Raytracing - Grundlagen II" <br><br />
Die Grundzüge des Raytracings Teil 2 - Einfache Basisobjekte, Transformationen und Phong-Lightning<br />
|}<br />
<br />
== Sonstiges ==<br />
{|{{Prettytable_B1}} width="100%"<br />
!width="15%"|Link<br />
!width="85%"|Beschreibung<br />
|-<br />
! [[Tutorial GLScene]]<br />
{{Level_1}} <br />
| [[Bild:Tutorial GLScene preview.jpg|right]] "Einführung in GLScene" <br><br />
GLScene ist eine zu erstaunlicher Größe angewachsene Komponentensammlung, die quasi einen OpenGL-Wrapper darstellt und euch dank Delphis VCL dadurch recht einfach OpenGL-Programme erstellen lässt. LaBoda gibt euch zu dieser Komponentensammlung in diesem Tutorial deshalb eine kleine Einführung.<br />
|}</div>Waranhttps://wiki.delphigl.com/index.php?title=Datei:Tutorial_ColorPicking_Screenie.png&diff=23969Datei:Tutorial ColorPicking Screenie.png2009-08-02T15:45:08Z<p>Waran: hat eine neue Version von „Datei:Tutorial ColorPicking Screenie.png“ hochgeladen</p>
<hr />
<div></div>Waranhttps://wiki.delphigl.com/index.php?title=Datei:Tutorial_ColorPicking_Screenie.png&diff=23968Datei:Tutorial ColorPicking Screenie.png2009-08-02T15:40:12Z<p>Waran: </p>
<hr />
<div></div>Waranhttps://wiki.delphigl.com/index.php?title=Datei:Endian.png&diff=23967Datei:Endian.png2009-08-02T15:27:14Z<p>Waran: </p>
<hr />
<div></div>Waranhttps://wiki.delphigl.com/index.php?title=Datei:AAc-Beispiel.png&diff=23966Datei:AAc-Beispiel.png2009-08-02T15:26:50Z<p>Waran: </p>
<hr />
<div></div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=21032TGA Bilder laden2007-12-12T19:50:15Z<p>Waran: /* TGA Dateien - Warum? */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Artikel geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von "neueren" OpenGL-Implementierungen (konkret: 1.2) direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Image Data Field - die eigentlichen Pixeldaten<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename);<br />
reset(f, 1);<br />
<br />
// type<br />
seek(f, 2);<br />
blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12);<br />
blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18);<br />
blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieser Artikel war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20691TGA Bilder laden2007-08-07T17:54:49Z<p>Waran: /* Definition eines Datentyps */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Artikel geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Image Data Field - die eigentlichen Pixeldaten<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename);<br />
reset(f, 1);<br />
<br />
// type<br />
seek(f, 2);<br />
blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12);<br />
blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18);<br />
blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieser Artikel war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20690TGA Bilder laden2007-08-06T18:26:05Z<p>Waran: </p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Artikel geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename);<br />
reset(f, 1);<br />
<br />
// type<br />
seek(f, 2);<br />
blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12);<br />
blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18);<br />
blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieser Artikel war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20687TGA Bilder laden2007-08-05T21:25:03Z<p>Waran: /* Die Datei laden */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename);<br />
reset(f, 1);<br />
<br />
// type<br />
seek(f, 2);<br />
blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12);<br />
blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18);<br />
blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20686TGA Bilder laden2007-08-05T21:24:23Z<p>Waran: /* Definition eines Datentyps */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2);<br />
blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12);<br />
blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18);<br />
blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20685TGA Bilder laden2007-08-05T21:21:28Z<p>Waran: /* Die Datei laden */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
"Packed" ist an dieser Stelle wichtig, da wir w,h und bpp in einem einzigen Zug einlesen<br />
werden und diese Variablen deshalb auch im Speicher nebeneinander liegen sollten (und es sonst,<br />
je nach dem wie der konkrete Compiler Daten standardmäßig anordnet, zu Problemen kommen kann).<br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2);<br />
blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12);<br />
blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18);<br />
blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20684TGA Bilder laden2007-08-05T21:20:57Z<p>Waran: /* Definition eines Datentyps */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
"Packed" ist an dieser Stelle wichtig, da wir w,h und bpp in einem einzigen Zug einlesen<br />
werden und diese Variablen deshalb auch im Speicher nebeneinander liegen sollten (und es sonst,<br />
je nach dem wie der konkrete Compiler Daten standardmäßig anordnet, zu Problemen kommen kann).<br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20683TGA Bilder laden2007-08-05T21:20:09Z<p>Waran: /* Definition eines Datentyps */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
"Packed" ist an dieser Stelle wichtig, da wir w,h und bpp in einem einzigen Zug einlesen<br />
werden und dese Variablen deshalb auch im Speicher nebeneinander liegen sollten (und es sonst,<br />
je nach dem wie der konkrete Compiler Daten standardmäßig anordnet, zu Problemen kommen kann).<br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20682TGA Bilder laden2007-08-05T21:01:17Z<p>Waran: </p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20681TGA Bilder laden2007-08-05T20:59:45Z<p>Waran: /* Landkarte und Kompass - oder besser GPS :D */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS? ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20680TGA Bilder laden2007-08-05T20:58:58Z<p>Waran: </p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20679TGA Bilder laden2007-08-05T20:58:48Z<p>Waran: </p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20678TGA Bilder laden2007-08-05T20:58:26Z<p>Waran: /* Ein Wort zur Kompression */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20677TGA Bilder laden2007-08-05T20:57:13Z<p>Waran: /* Ein Wort zur Kompression */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Ein Wort zur Kompression ==<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
Wer ein gutes Format mit Kompression sucht, ist mit Microsoft's DDS sehr gut<br />
beraten, da es ein Format ist, welches speziell für Texturen gedacht ist. Es<br />
bringt diverse Features wie MipMaps, 3D-Texturen, Cubemaps u.v.m. unterstützt.<br />
Zusätzlich unterstützen DDS-Dateien auch DXT-Kompression welche von der Grafikhardware<br />
dekomprimiert wird und somit Bandbreite spart - was die Render- und Ladegeschwindigkeit<br />
erhöht.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20676TGA Bilder laden2007-08-05T20:56:09Z<p>Waran: /* Ein Wort zur Kompression */</p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Ein Wort zur Kompression ==<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, die in den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
Wer ein gutes Format mit kompression sucht, ist mit Microsoft's DDS sehr gut<br />
beraten, da es ein Format ist, welches speziell für Texturen gedacht ist. Es<br />
bringt diverse Features wie MipMaps, 3D-Texturen, Cubemaps u.v.m. unterstützt.<br />
Zusätzlich unterstützen DDS-Dateien auch DXT-Kompression welche von der Grafikhardware<br />
dekomprimiert wird und somit Bandbreite spart - was die Render- und Ladegeschwindigkeit<br />
erhöht.<br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20675TGA Bilder laden2007-08-05T20:46:42Z<p>Waran: </p>
<hr />
<div>== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Ein Wort zur Kompression ==<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, diein den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
Als Alternative zu komprimierten TGA-Dateien bietet sich Microsoft's DDS-Format<br />
an, da es eine Komprimierung unterstützt, die direkt von der Grafikkarte gelesen<br />
werden kann - d.h. die Dateien werden kleiner, zusätzlich spart man Bandbreite<br />
und erhöht so effektiv die Lade- und Rendergeschwindigkeit.<br />
<br />
Alternativ lassen sich "normale" TGA's auch manuell mit einer effektiveren<br />
Methode als RLE packen (Stichwort: Virtuelles Dateisystem).<br />
Da dieses Tutorial aber eher für Anfänger gedacht ist gehe ich nun nicht weiter<br />
darauf ein :-) <br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20674TGA Bilder laden2007-08-05T20:40:49Z<p>Waran: </p>
<hr />
<div>= TGA Dateien Laden =<br />
<br />
== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Ein Wort zur Kompression ==<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, diein den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
Als Alternative zu komprimierten TGA-Dateien bietet sich Microsoft's DDS-Format<br />
an, da es eine Komprimierung unterstützt, die direkt von der Grafikkarte gelesen<br />
werden kann - d.h. die Dateien werden kleiner, zusätzlich spart man Bandbreite<br />
und erhöht so effektiv die Lade- und Rendergeschwindigkeit.<br />
<br />
Alternativ lassen sich "normale" TGA's auch manuell mit einer effektiveren<br />
Methode als RLE packen (Stichwort: Virtuelles Dateisystem).<br />
Da dieses Tutorial aber eher für Anfänger gedacht ist gehe ich nun nicht weiter<br />
darauf ein :-) <br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20673TGA Bilder laden2007-08-05T20:39:31Z<p>Waran: </p>
<hr />
<div>= TGA Dateien Laden =<br />
<br />
== TGA Dateien - Warum? ==<br />
<br />
In diesem Tutorial (mein erstes) geht es um das manuelle Laden von Truevision<br />
Bilddateien mit der allseits bekannten Endung ".tga".<br />
<br />
Dieses Dateiformat ist für den Anfang aus verschiedenen Gründen auf voller<br />
Linie empfehlenswert. Es ist sehr einfach aufgebaut und die Pixeldaten liegen<br />
auch schon in einer von neueren OpenGL-Implementierungen direkt benutzbaren<br />
Ordnung vor.<br />
<br />
== Landkarte und Kompass - oder besser GPS :D ==<br />
<br />
Zuerst stellen wir uns die Frage, wie eine TGA-Datei intern aufgebaut ist.<br />
Da es sich um eine Binärdatei handelt, lässt sich die Bedeutung der Daten nicht<br />
erraten - wir sind also auf fremde Dokumentation angewiesen.<br />
Eine ganze Sammlung solcher "Datei-Spickzettel" findet man auf der Internetseite<br />
http://www.wotsit.org/.<br />
<br />
Nachdem wir uns das entsprechende Dokument von dort besorgt und kritisch<br />
überflogen haben, fällt wohl erstmal ins Auge, dass es verschiedene Typen von<br />
TGA-Dateien zu geben scheint.<br />
<br />
Wir beschäftigen uns hier nur mit Typ 2 (24/32-Bit TGA ohne Kompression), da es<br />
das gebräuchlichste Format ist.<br />
<br />
== Ein Wort zur Kompression ==<br />
<br />
Komprimierte TGA-Dateien lassen wir außen vor,<br />
da sie leider einige Nachteile mit sich bringen: Es ist schwieriger die Datei<br />
einzulesen, das Dekodieren benötigt wertvolle Rechenzeit und die<br />
RLE-Kompression, diein den TGA-Dateien zum Einsatz kommt, ist vergleichsweise<br />
schlecht.<br />
<br />
Als Alternative zu komprimierten TGA-Dateien bietet sich Microsoft's DDS-Format<br />
an, da es eine Komprimierung unterstützt, die direkt von der Grafikkarte gelesen<br />
werden kann - d.h. die Dateien werden kleiner, zusätzlich spart man Bandbreite<br />
und erhöht so effektiv die Lade- und Rendergeschwindigkeit.<br />
<br />
Alternativ lassen sich "normale" TGA's auch manuell mit einer effektiveren<br />
Methode als RLE packen (Stichwort: Virtuelles Dateisystem).<br />
Da dieses Tutorial aber eher für Anfänger gedacht ist gehe ich nun nicht weiter<br />
darauf ein :-) <br />
<br />
== Definition eines Datentyps ==<br />
<br />
Welche Daten aus der TGA-Datei sind nun wirklich für unsere Zwecke interessant?<br />
<br />
<br />
Image Type Code - zum überprüfen, ob die Datei das richtige Format hat.<br />
Width of Image<br />
Height of Image<br />
Image Pixel Size - anhand dieser können wir u.a. ermitteln, ob ein Alphakanal<br />
vorhanden ist.<br />
Identification Field - die eigentlichen Pixeldaten.<br />
<br />
<br />
Damit haben wir alles benötigte zusammen und können diese Informationen schon<br />
mal in einen Verbundtyp packen (Die Datentypen entnehmen wir der "Length"-Spalte<br />
in unserem Dokument von wotsit):<br />
<br />
<pascal><br />
type<br />
TTGAFile = packed record<br />
iType: byte; // should be 2<br />
w, h: word; // Width, Height<br />
bpp: byte; // Byte per Pixel<br />
data: ^byte; // Pixels, dynamic length<br />
end;<br />
</pascal><br />
<br />
<br />
== Die Datei laden ==<br />
<br />
Die Schritte, die nun erforderlich sind, um diese Struktur mit Leben zu Füllen<br />
sind denkbar einfach. Zuerst wird die Datei binär geöffnet; der Dateizeiger mit<br />
Seek positioniert (siehe "Offset"-Spalte in unserem Dokument) und mit Blockread<br />
gelesen. Die Felder w, h und bpp liegen in der Datei nebeneinander; deshalb<br />
können sie mit nur einer einzigen (anstatt 3) Seek/Blockread-Kombination<br />
eingelesen werden. Da wir mit "Bit pro Pixel" wenig anfangen können teilen wir<br />
bpp anschließend durch 8 und erhalten "Bytes pro Pixel".<br />
<br />
Hinweis: Für den, der es an dieser Stelle lieber objektorientiert mag, bieten<br />
sich natürlich auch Streams an. Allerdings ist dies für diesen<br />
konkreten Fall nicht von Belang.<br />
<br />
<pascal><br />
function LoadTGA(const filename: string): TTGAFile;<br />
var f: file; bytes: longword;<br />
begin<br />
assign(f, filename); reset(f, 1);<br />
<br />
// type<br />
seek(f, 2); blockread(f, result.iType, 1);<br />
<br />
// w, h, bpp<br />
seek(f, 12); blockread(f, result.w, 5);<br />
result.bpp := result.bpp div 8;<br />
<br />
// data<br />
bytes := result.w * result.h * result.bpp;<br />
getmem(result.data, bytes);<br />
seek(f, 18); blockread(f, result.data^, bytes);<br />
<br />
close(f);<br />
end;<br />
</pascal><br />
<br />
Diese Funktion lädt alle benötigten Daten aus der Datei; reserviert auf Basis<br />
dieser Informationen genug Speicher für die Pixeldaten und liest sie dann ein.<br />
Der Pointer kann anschließend direkt in OpenGL verwendet werden, wenn die<br />
Implementierung die Formate GL_BGR und GL_BGRA unterstützt (je nach dem, ob<br />
"bpp" den Wert 3 oder 4 erhalten hat).<br />
<br />
== Datei rein - Textur raus ==<br />
<br />
Die eigentliche Erzeugung des Texturobjektes gleicht dem "SDL-Weg". Nur wird<br />
hier unser eigenes Record anstatt einer SDL-Surface verwendet. Nicht vergessen<br />
den dynamisch reservierten Speicher für die Pixeldaten nach der Verwendung mit<br />
<pascal><br />
FreeMem(TGARecord.data);<br />
</pascal><br />
wieder freizugeben!<br />
<br />
<pascal><br />
procedure TGATexture(const filename: string; var TexID: longword);<br />
var<br />
tex: TTGAFile;<br />
glFormat: longword;<br />
begin<br />
tex := LoadTGA(filename);<br />
if tex.iType = 2 then<br />
begin<br />
glGenTextures(1, @TexID);<br />
glBindTexture(GL_TEXTURE_2D, TexID);<br />
<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);<br />
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);<br />
<br />
if tex.bpp = 3 then glFormat := GL_BGR<br />
else glFormat := GL_BGRA;<br />
<br />
glTexImage2D(GL_TEXTURE_2D, 0, tex.bpp, tex.w, tex.h,<br />
0, glFormat, GL_UNSIGNED_BYTE, tex.data);<br />
<br />
FreeMem(tex.data);<br />
end;<br />
end;<br />
</pascal><br />
<br />
Ich hoffe dieses Tutorial war hilfreich (Ich will Feedback!) und wünsche euch<br />
viel Spaß und Erfolg bei euren zukünftigen Projekten.<br />
<br />
Gruß Waran.</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20670TGA Bilder laden2007-08-04T01:23:00Z<p>Waran: </p>
<hr />
<div>{{Offline}}</div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20669TGA Bilder laden2007-08-04T00:59:33Z<p>Waran: Die Seite wurde geleert.</p>
<hr />
<div></div>Waranhttps://wiki.delphigl.com/index.php?title=TGA_Bilder_laden&diff=20668TGA Bilder laden2007-08-04T00:59:02Z<p>Waran: Die Seite wurde neu angelegt: [Inhalt wird von Phobeus gesichtet]</p>
<hr />
<div>[Inhalt wird von Phobeus gesichtet]</div>Waran