https://wiki.delphigl.com/api.php?action=feedcontributions&feedformat=atom&user=Delphic 2026-05-30T22:19:42Z Benutzerbeiträge MediaWiki 1.27.4 https://wiki.delphigl.com/index.php?title=Tutorial_Software-Synthesizer&diff=25494 2012-03-07T06:14:46Z

<p>Delphic: /* Abschluss */ Source files verlinkt</p> <hr /> <div>==Über Schall und Digitalisierung==<br /> <br /> Schall ist, wie sicherlich Jeder weis, nichts anderes als Druckschwankungen im uns umgebenden Medium: meist Luft. Aber er lässt sich auch gut durch Wasser oder Metall übertragen, nur vor dem Nichts, dem Vakuum, muss er kapitulieren. Die Druckschwankungen werden vom Trommelfell in unserem Ohr auf ein Knochensystem und von diesem auf das eigentliche Hörorgan übrtragen, welches über feine Haare die Druckschwankungen in Nervensignale übersetzt. Unser Gehirn bereitet die Daten auf, wobei ein subjektiver Eindruck entsteht - wir hören.<br /> <br /> Dabei ist unser Ohr im Stande, unterschiedliche Frequenzen als solche einzeln wahrzunehmen. Das ist insofern etwas besonderes, da unser Auge genau das nicht kann. Treffen auf die Netzhaut gleich intensiv und gemeinsam blaues und gelbes Licht, so entsteht ein grüner Farbeindruck. Unser Ohr, würde es nicht auf Schall, sondern auf elektromagnetische Wellen reagieren, würde das Blau und das Gelb als solche einzeln identifizieren können. Manche Menschen haben im übrigen eine andere Sehstäbchenzusammensetzung auf der Netzhaut, als der &quot;normale&quot; Mensch - so empfinden einige das gemischte Computergelb als eine andere Farbe, als das &quot;echte&quot; Gelb.<br /> <br /> Nun wollten wir uns aber nicht mit dem Sehen, sondern mit dem Hören beschäftigen. Um Schall zu digitalisieren und damit in Computertaugliche Form zu bringen, benutzt man Mikrofone. Diese besitzen eine Membran, die durch die Druckveränderungen der umgebenden Luft in Schwingung versetzt wird. An einer Stelle der Membran befindet sich eine Spule, in einem Magnetfeld. Wird die Membran durch Schall bewegt, wird die Spule im Magnetfeld bewegt: es entsteht ein Induktionsstrom, der nach Verstärkung ein elektrisches Signal liefert. Dieses Signal könnte man z.B. an einen Lautsprecher weiterleiten und so wieder vertonen.<br /> <br /> In unserem Falle wollen wir die Signaldaten jedoch digitalisieren. Dazu wird ein Analog/Digitalwandler verwendet, der die unterschiedlichen Spannungen in Zahlenwerte umwandelt (digitalisiert). Das analoge Signal ist durchgängig, während digitale Daten immer nur kleine Abschnitte des Signals darstellen können, weshalb das Signal gesampelt wird: In einer Sekunde werden gleichverteilt die Signalpegel des analogen Signals in eine Reihe Zahlenwerte umgewandelt. Die Anzahl der Zahlenwerte pro Sekunde wird als Samplingrate bezeichnet. Audio CDs werden mit 44,1 kHz gesampelt, d.h. pro Sekunde wird das analoge Signal des Mikrofons 44100 mal in einen digitalen Wert, ein Sampel, übersetzt.<br /> <br /> Wir wollen jedoch den umgekehrten Weg gehen: Wir wollen eine Reihe Sampels selbst erzeugen, um so wohlklingende Töne zu erzeugen, die wir dann als Sounds oder Musik in unseren Projekten einsetzen können. Bis dahin ist es ein längerer Weg. Lest das Tutorial nicht zu schnell, pausiert auch hin und wieder mal, damit ihr das gelernte ausprobieren könnt. Eigene Ideen können häufig auch sehr interessant klingendes hervorbringen. Probiert einfach mal ein wenig rum, aber denkt immer daran, dass, solltet ihr einmal nichts hören können, ein aufdrehen der Lautsprecher ungesund werden könnte. Bleibt mit dem Regler in den Bereichen, die ihr auch sonst nutzt.<br /> <br /> Für viele der hier gezeigten Experimente ist hochwertiges Equipment zu empfehlen. Es kann durchaus sein, dass durch billige Boxen euch einige Erkenntnisse verwehrt bleiben, weil die Sache einfach nicht so klingt, wie sie soll. Da klappert mal etwas mit und schon verändert sich der Ton oder es entstehen zusätzliche, andersfrequente Töne, die den klaren Eindruck trüben. Die 5 Euro Boxen, die zum üblichen Komplettsystem gehören sind in keinem Fall geeignet. Auch eine ordentliche Soundkarte wäre zu empfehlen, wobei diese noch nicht einmal neu sein muss - auch eine alte Soundblaster AWE-32 wäre vollkommen ausreichend: nur hochwertig muss sie sein. Ach ja, eine 16-Bit Soundkarte sollte es dann schon sein ;-) Viele Onboard Soundkarten tuns auch, nur leider nicht alle :-(.<br /> <br /> {{Warnung|Dieses Tutorial wird euch den Weg in die faszinierende Welt der Software Synthese ebnen. Dies kann jedoch zu gesundheitlichen und materiellen Schäden führen, wenn ihr nicht ein paar grundlegende Dinge beachtet. Euer Gehör ist empfindlich und eure Boxenmembranen sind teuer. Vor Versuchen sollte immer mit einem euch bekannten Programm, die Lautstärkepegel eurer Soundkarte und eures Boxensystems überprüft werden. Zu hohe Lautstärken schaden euch und euren Boxen/Verstärkern oder allem, was sonst dazwischen hängt. Geht die Sache verantwortungsvoll an und ihr werdet viel Spass haben.}}<br /> <br /> ==Voreinstellungen==<br /> <br /> Um direkt Töne aus den Boxen zu zaubern, werden wir uns der FMOD Bibliothek bedienen. Ich habe hier nicht vor, diese Bibliothek bis ins Kleinste zu erklären. Es dürfte genügen, wenn ihr euch die zugehörigen Tutorials anschaut. Zum Abspielen werden wir uns der Callbackfunktionalität der Bibliothek bedienen, d.h. FMOD ruft eine von uns definierte Funktion immer wieder auf. Diese wird dann die nächsten, gesampelten Daten zurückgeben, so dass diese dann auf der Soundkarte ausgegeben werden.<br /> <br /> Da FMOD eine ganze Reihe Treiber für unterschiedliche Soundsysteme mitbringt, müssen ein paar Einstellungen getroffen werden. Damit das nicht bei jedem Programmstart geschieht, habe ich ein kleines Programm geschrieben, dass für alle der hier geschriebenen Programme entsprechende Voreinstellungen trifft und abspeichert. Bevor ihr weitermacht, startet einmal '''fmodconf''', stellt das ganze eurem System entsprechend ein und drückt auf Save:<br /> <br /> [[Bild:Tutorial_SoftSynth_konfiguration.png]]<br /> <br /> ==Der erste Ton==<br /> <br /> Der einfachste Ton, der von unserem Gehör als eindeutig nur zu einer Frequenz zugeordnet wird, lässt sich mit einer Sinuskurve beschreiben. Das gleiche erzeugen im übrigen auch gute Stimmgabeln, mit denen ihr sicherlich schon alle einmal im Physik- oder Musikunterricht Freundschaft schliessen konntet. Das ganze klingt sehr dünn, aber das ist genau das, was ich euch zeigen möchte.<br /> <br /> Zuerst sollten wir jedoch ein paar wesentliche Begriffe einer Welle klären:<br /> <br /> [[Bild:Tutorial_SoftSynth_welle.png]]<br /> <br /> Dieses Diagramm zeigt den durch ein gutes Mikrofon erzeugten Verlauf der Spannung auf der Zeit an, wenn eine angeschlagene Stimmgabel einen Ton erzeugt.<br /> <br /> {|{{Prettytable}}<br /> |'''Amplitude(A)''': Der Betrag des stärksten Ausschlags der Welle. Eine grössere Amplitude erzeugt einen lauteren Ton - und umgekehrt.<br /> |-<br /> |'''Periodendauer(T)''': Die Dauer einer vollständigen Schwingung.<br /> |-<br /> |'''Frequenz''': Die Zahl der vollständigen Schwingungen in einer Zeiteinheit. Sie wird üblicherweise pro Sekunde betrachtet:<br /> <br /> :f = 1 / T Einheit: 1/s=1Hz<br /> <br /> :Die Frequenz eines Tones bestimmt indirekt auch die empfundene Lautstärke, da durch die mechanische Übertragung des Schalls in unserem Ohr bestimmte Frequenzbereiche besser, andere schlechter übertragen werden.<br /> |-<br /> |'''Schallgeschwindigkeit''': Die Geschwindigkeit, mit der sich der Schall vorwärtsbewegt: 331 m/s in der Luft.<br /> |-<br /> |'''Wellenlänge''': Ist die Länge einer Welle. Sie errechnet sich aus der Schallgeschwindigkeit geteilt durch die Frequenz.<br /> |}<br /> <br /> Nun wollen wir also eine Stimmgabel mit dem Computer simulieren. Alles was wir dazu machen müssen, ist eine Sinuskurve an FMOD zu übergeben. Wie bereits erklärt, wird eine Sekunde in eine Reihe Sampels zerlegt. Wir wollen mit einer Scrollbar die Frequenz des Tones einstellen können:<br /> <br /> '''ssynth1:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> var<br /> Pos : Integer;<br /> Freq : Integer;<br /> <br /> function StreamCallback(Stream: PFSoundStream; Buff: Pointer; Len, Param: Integer): ByteBool; stdcall;<br /> var<br /> Count: Integer; <br /> Buffer: PChar;<br /> <br /> begin<br /> Freq := SinGenForm.FreqBar.Position;<br /> Buffer := PChar(Buff);<br /> Count := 0;<br /> <br /> while Count &lt; (Len div 4) do { div 4 = 16bit stereo (4 bytes per sample) }<br /> begin<br /> PSmallInt(Buffer)^ := Trunc(Sin(2*Pi/SamplingRate*Freq*Pos) * (32767.0/2.0)); { Left channel }<br /> Inc(Buffer, 2);<br /> PSmallInt(Buffer)^ := Trunc(Sin(2*Pi/SamplingRate*Freq*Pos) * (32767.0/2.0)); { Right channel }<br /> Inc(Buffer, 2);<br /> <br /> Inc(Count);<br /> Inc(Pos);<br /> end;<br /> <br /> Result := True;<br /> end;<br /> &lt;/source&gt;<br /> <br /> Die Variable Pos dient dem linearen Voranschreiten in unserer Sinuskurve. Durch das Teilen durch die Sampling-Rate erreichen wir, dass jede Sekunde ein Bereich von '''k''' bis '''k+1''' durchlaufen wird, also ein Intervall der Länge '''1: [0..1]+k'''; Wenn durch unsere Zählvariable jede Sekunde ein Bereich der Länge '''1''' durchlaufen wird, wird die Sache für uns viel einfacher. Durch die Multiplikation mit der Frequenz, wird dann nämlich ein Intervall von '''[0..Freq]''' durchlaufen und wir sind nahe dran an dem, was wir haben wollen. Wir müssen nur bedenken, dass der Sinus eine volle Schwingung im Bereich '''[0..2*Pi]''' beschreibt, also multiplizieren wir mit '''2*Pi''' und erzeugen damit eine Sinus-Kurve, die in einer Sekunde '''Freq''' viele Schwingungen macht. Es wird Zeit zum Ausprobieren von synth1. Das Programm ist im im übrigen auf den Kammerton a: 440Hz voreingestellt - nur damit wir gleich mal den Bezug zur Musik herstellen. ;-)<br /> <br /> ==Die Schwebung==<br /> <br /> Wir wollen unserer Stimmgabel eine weitere, gleichlaute Stimmgabel hinzufügen. Diese ist um wenige Frequenzteile verstimmt, so dass die Frequenzen wirklich sehr nahe beieinander liegen. Mit unserer Scrollbar wollen wir diesmal nicht einen großen Frequenzbereich abdecken, sondern nur eine Möglichkeit zum manipulieren des Anteils schaffen. Die Hauptfrequenz legen wir auf 880 Hz fest. Freundlicherweise genügt es, die zweite Stimmgabel durch Addition einer zweiten Sinuskurve hinzuzufügen - wir müssen nur darauf achten, dass wir dann in dem uns begrenzenden Werteintervall bleiben:<br /> <br /> [[Bild:Tutorial_SoftSynth_schwebgen.png]]<br /> <br /> Bewegt man den Regler an den äusseren Rand, so nimmt man zwei erkennbar unterschiedliche Töne wahr. Kommt man der Mitte näher, verändert sich das Klangbild stark. Es entsteht eine art Pulsierender Ton. Dieser Effekt kommt häufig in Musikinstrumenten zum Einsatz, so hat jede Taste im Klavier drei zugehörige Saiten, die leicht gegeneinander verstimmt sind, so dass sie einen schwebungstypischen Klang erzeugen.<br /> <br /> Wer will, soll einmal einen typischen Audioeditor starten, etwa den kostenlosen Audacity, und betrachte damit einmal den Funktionsgraphen. Einen derartigen Audioeditor solltet ihr für eure Versuche immer parat halten, um bei bedarf mal genau hinzusehen, was ihr da eigentlich erzeugt und ob das dem entspricht, was ihr euch vorgestellt habt.<br /> <br /> {{Hinweis|<br /> Um die Ergebnisse der bislang gemachten Versuche bestaunen zu können, startet den jeweiligen Generator und nehmt einfach ein Stück mit einem Audioeditor auf. Vergesst dabei nicht, die Aufnahmeeinstellungen der Soundkarte entsprechend anzupassen.<br /> }}<br /> <br /> '''ssynth2:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function StreamCallback(Stream: PFSoundStream; Buff: Pointer; Len, Param: Integer): ByteBool; stdcall;<br /> var<br /> Count: Integer;<br /> Buffer: PChar;<br /> Value : Single;<br /> Delta : Single;<br /> <br /> begin<br /> Freq := 880;<br /> Buffer := PChar(Buff);<br /> Count := 0;<br /> <br /> Delta := 1.0 + (1/10000.0 * SchwebGenForm.PercentBar.Position);<br /> <br /> while Count &lt; (Len div 4) do <br /> begin<br /> Value := (Sin(2*Pi/SamplingRate*Freq*Pos) + Sin(2*Pi/SamplingRate*Freq*Pos*Delta));<br /> PSmallInt(Buffer)^ := Trunc(Value * (32767.0/2.0)); { Left channel }<br /> Inc(Buffer, 2);<br /> PSmallInt(Buffer)^ := Trunc(Value * (32767.0/2.0)); { Right channel }<br /> Inc(Buffer, 2);<br /> <br /> Inc(Count);<br /> Inc(Pos);<br /> end;<br /> <br /> Result := True;<br /> end;<br /> &lt;/source&gt;<br /> <br /> ==Andere Wellenformen==<br /> <br /> Statt Sinusförmigen Wellen, bietet es sich an, pulsierende, dreieckige oder jegliche Arten anderer, (periodischer) Funktionen zu verwenden. Diese klingen dann teilweise etwas ungewöhnlich, aber wesentlich voller als der typische Sinuston. Dies liegt daran, dass, würde man die Graphen aus Sinuskurven nachbauen, so würde man die Sinus-Graphen aus ganzen Frequenzbändern benötigen, wodurch das gehörte Frequenzspektrum natürlich stark zunimmt. Der Effekt: Der Ton hört sich wesentlich voller an.<br /> <br /> Ein wertvolles Hilfsmittel zur Analyse der dadurch &quot;betonten&quot; Frequenzbereiche ist die Fourier Analyse. FMOD bietet eine leicht zugängliche API, um eine ganze Reihe Frequenzbänder zu untersuchen. Das bedeutet für uns: Ab sofort benötigt jeder unserer Synthesizer ein Display zur Frequenzanalyse. Leider sind diese Analysen nie so recht perfekt, aber um einen Eindruck der belegten Frequenzen zu erhalten, genügt es allemal.<br /> <br /> ===Sinus===<br /> <br /> [[Bild:Tutorial_SoftSynth_sinus.png]]<br /> <br /> Der altbekannte Sinus muss natürlich zum Vergleich wieder mit dabei sein:<br /> <br /> '''ssynth3:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function SinWave(x: Single): Single;<br /> begin<br /> Result := Sin(2*Pi*x);<br /> end;<br /> &lt;/source&gt;<br /> <br /> ===Dreieck===<br /> <br /> [[Bild:Tutorial_SoftSynth_dreieck.png]]<br /> <br /> Das Dreieck klingt ähnlich wie der Sinus, nur ein wenig voller. Dass beide sehr verwand sein müssen, lässt sich ja bereits am Graphen erkennen.<br /> <br /> '''ssynth3:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function DreieckWave(x: Single): Single;<br /> begin<br /> Result := Abs(frac(x) - 0.5) * 4 - 1;<br /> end;<br /> &lt;/source&gt;<br /> <br /> ===Sägezahn===<br /> <br /> [[Bild:Tutorial_SoftSynth_saegezahn.png]]<br /> <br /> Der Sägezahn klingt dann schon wesentlich voller und bissiger, aber macht euch am besten selbst ein Bild - man muss es gehört haben, um zu wissen wie es klingt ;-)<br /> <br /> '''ssynth3:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function SaegezahnWave(x: Single): Single;<br /> begin<br /> Result := (-1 + 2 * frac(x));<br /> end;<br /> &lt;/source&gt;<br /> <br /> ===Puls===<br /> <br /> [[Bild:Tutorial_SoftSynth_puls.png]]<br /> <br /> Der Puls schlägt dann schon sehr aus der Reihe. Durch Veränderunge der Länge der gleichartigen Bereiche, kann man den klang sehr gut und einfach manipulieren.<br /> <br /> '''ssynth3:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function PulseWave(x: Single): Single;<br /> function Sgn(x : Single) : Single;<br /> begin<br /> if x &lt; 0 then<br /> Result := -1.0<br /> else<br /> Result := +1.0;<br /> end;<br /> begin<br /> Result := Sgn(frac(x) - IrgendwasZwischen0undEinhalbes);<br /> end;<br /> &lt;/source&gt;<br /> <br /> ===Rauschen===<br /> <br /> [[Bild:Tutorial_SoftSynth_rauschen.png]]<br /> <br /> Nun, dieser Klang ist sehr charakteristisch und ich vermute jeder kennt ihn längst ;-) Wers nicht erkennt, möge ihn sich anhören.<br /> <br /> '''ssynth3:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function RauschenWave(x: Single): Single;<br /> begin<br /> Result := (Random -0.5)*2;<br /> end;<br /> &lt;/source&gt;<br /> <br /> ==Hausgemachte Ober- und Untertöne==<br /> <br /> Durch unterschiedliche Wellenformen können wir nun unseren Tönen etwas mehr Fülle verleihen. Es bietet sich jedoch noch eine weitere Möglichkeit an: Obertöne. Statt einer einzelnen Sinuskurve werden hier eine ganze Reihe an Sinuskurven übereinandergelegt. Deren Amplitude ist immer etwas geringer, als die des Haupttones, deren Frequenz jedoch um den Faktor 2^n erhöht:<br /> <br /> '''ssyth4:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> Ton := 20 * SinWave(x);<br /> Ton := Ton + 10 * SinWave(x*2); //1 Oktave höher als der Grundton<br /> Ton := Ton + 7 * SinWave(x*4); //2 Oktaven höher als der Grundton<br /> Ton := Ton + 5 * SinWave(x*8); //3 Oktaven höher als der Grundton<br /> ...<br /> Ton := 1.0/(20+10+7+5+...)*Ton;<br /> &lt;/source&gt;<br /> <br /> Äquivalent kann man auch Untertöne erzeugen: Statt Oktavschritte nach oben, geht man Oktavschritte mit der Frequenz nach unten (teilen durch 2):<br /> <br /> '''ssyth4:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> Ton := 20 * SinWave(x);<br /> Ton := Ton + 10 * SinWave(1/2*x); //1 Oktave niedriger als der Grundton<br /> Ton := Ton + 7 * SinWave(1/4*x); //2 Oktaven niedriger als der Grundton<br /> Ton := Ton + 5 * SinWave(1/8*x); //3 Oktaven niedriger als der Grundton<br /> ...<br /> Ton := 1.0/(20+10+7+5+...)*Ton;<br /> &lt;/source&gt;<br /> <br /> ==Hüllkurven oder Attack, Decay, Sustain, Release Envelopes==<br /> <br /> Obwohl sich das alles noch sehr langweilig anhört und an sich nicht wesentlich mehr als ohrenbetäubendes quietschen ist, sind wir schon sehr weit fortgeschritten. Eigentlich fehlt uns gar nicht mehr viel, um wohlgeformte Klänge aus den Boxen zu zaubern. Bevor wir das jedoch tun können, benötigen wir noch ein kleines Hilfsmittel: eine Hüllkurve. Das ist an sich nicht mehr, als ein simulierter Lautstärkenverlauf des Anschlages eines Instrumentes, der sich bei vielen Instrumenten in 4 Teilbereiche aufspaltet:<br /> <br /> '''Attack''': Der Attack-Teil beschreibt den Lautstärkenverlauf direkt beim und nach dem Anschlag. Die Saite gibt vorerst keinen Ton von sich. Durch Zupfen oder Anschlagen schnellt der von ihr erzeugte Schalldruck in kurzer Zeit auf sein Maximum. Danach fällt die Lautstärke während der '''Decay-Phase''' auf einen mittleren Wert zurück, verweilt dann in der '''Sustainphase''' eine Zeit lang auf nahezu konstantem Niveau (für uns soll echt konstant genügen), worauf sich die '''Releasephase''' anschliesst, in der der Ton - häufig gedämpft - ausklingt:<br /> <br /> Prinzip einer ADSR_Hüllkurve:<br /> <br /> [[Bild:Tutorial_SoftSynth_adsr-prinzip.png]]<br /> <br /> Zur Lautstärkenregulierung bietet sich die Amplitude unserer Wellenfunktionen an, die wir ganz einfach durch Multiplikation des Sampels mit einem Wert zwischen Null und Eins nach belieben manipulieren können. Daneben müssen wir jedoch beachten, dass unser Gehör auf exponentiell steigende &quot;Werte&quot; geeicht ist, der einfache Kurvenverlauf auf dem obigen Bild würde seltsam klingen. Wandeln wir den Graphen also ein wenig um:<br /> <br /> [[Bild:Tutorial_SoftSynth_adsr-huellfunktion.png]]<br /> <br /> Mithilfe der '''exp''' Funktion sollte ein Jeder imstande sein, eine entsprechende Funktion zusammenzustöpseln.<br /> <br /> '''Etwas ADSR-Hüllkurvenquellcode:'''<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function ADSREnvelope(t, a, d, s, r, maxlevel, holdlevel : Single): Single;<br /> const<br /> e = 2.71828182846;<br /> <br /> Start = -4.65;<br /> Intervallaenge = 1.0 - Start;<br /> <br /> var<br /> Pos, x, delta : Single;<br /> begin<br /> if t &lt; 0 then<br /> begin<br /> Result := 0;<br /> Exit;<br /> end;<br /> <br /> //Attack<br /> Pos := a;<br /> if t &lt; Pos then<br /> begin<br /> x := 1.0 - t/a; //x zwischen 0 und 1<br /> x := x * Intervallaenge + Start; //x auf das Intervall mappen<br /> Result := (1.0 - 1/e*(Power(e, x)))*maxlevel;<br /> Exit;<br /> end;<br /> <br /> //Decay<br /> Pos := Pos + d;<br /> if t &lt;= Pos then<br /> begin<br /> delta := maxlevel - holdlevel;<br /> if delta &lt;= 0.0 then<br /> begin<br /> Result := holdlevel;<br /> Exit<br /> end;<br /> x := 1.0 - (t - Pos + d)/d;<br /> x := x * Intervallaenge + Start;<br /> Result := Maxlevel - (1.0 - 1/e*(Power(e, x)))*delta;<br /> Exit;<br /> end;<br /> <br /> //Sustain<br /> Pos := Pos + s;<br /> if t &lt;= Pos then<br /> begin<br /> Result := holdlevel;<br /> Exit<br /> end;<br /> <br /> //Release<br /> Pos := Pos + r;<br /> if t &lt;= Pos then<br /> begin<br /> x := 1.0 - (t - Pos + r)/r;<br /> x := x * Intervallaenge + Start;<br /> Result := holdlevel - holdlevel * (1.0 - 1/e*(Power(e, x)));<br /> Exit;<br /> end;<br /> <br /> Result := 0.0;<br /> end;<br /> &lt;/source&gt;<br /> <br /> Zusätzlich benötigen wir noch ein paar weitere Hüllkurven, die ich hier jedoch etwas weniger ausführlich beschreiben werde:<br /> <br /> Eine Attack-Sustain-Release-Hüllkurve hat, wie ihr Name verrät 3 Phasen. Im Attack Bereich schwillt die Lautstärke auf ihr Maximum, bleibt dann im Sustain Bereich auf diesem Niveau, um schließlich wieder wie gehabt in der Release-Phase abzufallen.<br /> <br /> Eine abbrechbare Attack-Decay-Hüllkurve: Der Attack Bereich ist wie gehabt. In der Decay-Phase fällt die Lautstärke bis auf das Null Niveau ab. Dieser Vorgang kann jedoch an jeder beliebigen Stelle abgebrochen werden und in eine gedämpfte Release-Phase übergehen.<br /> <br /> ==Ein paar synthetische Musikinstrumente==<br /> <br /> Nun wird es wirklich einmal Zeit, Töne zu erzeugen, bei denen man sich nicht nach kürzester Zeit gequält die Ohren zuhalten muss. Eine gute Möglichkeit dies zu erreichen, besteht darin echte Musikinstrumente zu simulieren. Die einfachen Mittel, die wir bis jetzt kennengelernt haben, reichen dafür völlig aus. Ich werde hier nicht an jeder Stelle Quellcodes mitliefern, ein Blick in die Dateien des synth5 Projektes sollte jedoch Klarheit schaffen. Beim Nachstellen eines Instrumentes ist v.a. ein wenig mit den Parametern spielen angesagt - den Spass will ich euch nicht nehmen. Viele meiner Instrumente sind sicherlich noch verbesserungsfähig.<br /> <br /> ===Klavier===<br /> <br /> Das Öffnen eines Klavieres kann uns sehr dabei helfen, herauszufinden, wie wir einen Ton synthetisieren müssen. Das typische Klavier besitzt 52 weiße Tasten, die mechanisch die ihnen zugehörigen Saiten mit einem Hammer anschlagen. Zu jeder Taste gehören 3 gespannte, metallische Saiten, die leicht gegeneinander verstimmt sind, so dass eine Schwebung entsteht. Ein Klavier hat einen sehr vollen Ton, so dass wir davon ausgehen können, dass jeder Ton aus einer ganzen Reihe an sinusförmigen Obertönen besteht.<br /> <br /> Kommen wir noch zu unserer Hüllkurve: Durch den Anschlag mit dem Hammer steigt die Lautstärke schnell auf ihr Maximum. Bei längerem Tastendruck fällt die Lautstärke langsam ab und wird nach dem loslassen stark gedämpft (Durch Benutzung der unteren Pedale lässt sich hier viel verändern - d.h. hier kann man ruhig ein wenig variieren und herumspielen). Wesentlich an den Hüllkurven ist jedoch, dass die einzelnen Abschnitte der AD-Hüllkurve in ihrer Länge von der Frequenz des Grundtones abhängig sind, weshalb man die Längen nicht in Zeitdauern angibt, sondern durch die Zahl der Schwingungen.<br /> <br /> ===Klavinett===<br /> <br /> Das Klavinett ist dem Klavier sehr sehr ähnlich. Um seine etwas rauheren Töne zu synthetisieren eignen sich Dreiecke oder Sägezähne sehr gut. Mit Dreiecken klingt das Klavinett ziemlich sanft, mit Sägezähnen dagegen schon sehr hart - was die zweite Variante in Verbindung mit tiefen Tönen sehr imposant erscheinen lässt. An den Hüllkurven des Klaviers muss man dagegen nichts ändern.<br /> <br /> ===Flöte===<br /> <br /> Wir wollen uns hier mit einer einfachen Flöte begnügen: Man nehme eine ASR-Hüllkurve und eine Dreiecks-Schwingung. Testweise kann man auch einen Sägezahn ausprobieren, der dann zwar nicht mehr nach einer Flöte klingt, jedoch in den tiefen Tönen sehr schöne Ergebnisse liefert. Die Attack und Release Zeiten sollten sich ähneln. Üblicherweise wählt man sie rel. kurz.<br /> <br /> ===Glocken===<br /> <br /> Glocken geben einen sehr untertonreichen, feinen Klang von sich, entsprechend wählt man als Wellenfunktion den Sinus. Bei vielen Glocken lässt sich auch eine Schwebung heraushören. Als Hüllkurve wählt man wie beim Klavier einen AD-Envelope.<br /> <br /> ==Oktaven, Halbtöne und was sonst dazugehört==<br /> <br /> Wer sich Synth5 schon ein wenig genauer angeschaut hat, wird festgestellt haben, dass sich dort die Frequenzen für die Töne nicht mehr frei wählen lassen, sondern eine Klaviatur zur Eingabe dient. Wollen wir also ein paar Worte zur Berechnung der Frequenzen, die zu den einzelnen Tasten gehören, verlieren:<br /> <br /> Ein Oktavschritt verdoppelt die Frequenz, um also vom Kammerton a auf a' zu kommen, muss 440Hz * 2 gerechnet werden (Kammerton a ist auf 440Hz bzw. 436Hz festgelegt).<br /> <br /> Eine Oktave soll dann in 12 Teile zerlegt werden, so dass durch Multiplikation mit einem Faktor der nächst höhere Ton entsteht: Da eine Oktave einer Frequenzverdoppelung entspricht, muss für einen Halbton mit dem Faktor 12te Wurzel aus 2 = 2^(1/12) multipliziert werden.<br /> <br /> ==Abschluss==<br /> <br /> Wer etwa 14 MB Festplattenplatz frei hat, möge einmal [http://files.delphigl.com/new/softsynth_src.zip synth_test] starten, um Beethovens Für-Elise mit Glocken gespielt zu hören. Wenn Interesse besteht, werde ich den Synthesizer vielleicht auch noch vor dem Projekt veröffentlichen, zu dem er eigentlich gehört: Ein bischen Feedback wäre sicher angebracht.<br /> <br /> Ich hoffe eure Ohren haben diesen Angriff meinerseits gut überstanden. Vielleicht konnte ich dieses Thema ja halbwegs entmystifizieren, wo es doch eigentlich eine ganz andere Thematik als die üblichen DGL Tutorials beschreibt. Ich fand es jedenfalls faszinierend, hier in eine auch für mich bis dato völlig unbekannte Welt vorzustossen, wobei das Meiste einfach aus reinem Ausprobieren entstanden ist. Gut, ich muss zugeben, dass ich hin und wieder in ein altes Buch zum Synthesizer löten gespickt habe und auch mein Dad hi und da mit Rat zur Seite stand - tagelanges rumspielen mit Geräuschen, die durchs gesamte Haus hallen können nunmal nicht ungehört bleiben. Jemand, der selbst in seinen jüngeren Jahren einmal einen Synthesizer gebaut hat, lässt es eben nicht kalt, wenn bekannte Geräusche ertönen - wenn auch nicht analog mit Schaltungen, sondern digital erzeugt ;-).<br /> <br /> Euer Delphic<br /> <br /> <br /> <br /> {{TUTORIAL_NAVIGATION| [[Tutorial Multithreading]] |-}} <br /> <br /> [[Kategorie:Tutorial|Software-Synthesizer]]</div>

Delphic https://wiki.delphigl.com/index.php?title=SDL_keysym&diff=24343 2009-12-09T11:45:00Z

<p>Delphic: Unicode -&gt; UNICODE</p> <hr /> <div>= SDL_keysym =<br /> <br /> <br /> <br /> == Name ==<br /> '''SDL_keysym''' - Enthält Informationen über die gedrückte Taste<br /> <br /> <br /> <br /> == Delphi-Spezifikation ==<br /> type '''TSDL_keysym''' = record<br /> ''scancode'' : UInt8; <br /> ''sym'' : TSDLKey; <br /> ''modifier'' : TSDLMod; <br /> ''unicode'' : UInt16; <br /> end;<br /> <br /> <br /> <br /> <br /> == Parameter ==<br /> <br /> {| border=&quot;1&quot; rules=&quot;all&quot;<br /> ! ''scancode'' <br /> | Hardware spezifischer Scancode<br /> |-<br /> ! ''sym'' <br /> | SDL virtual keysym (siehe [[SDLKey]])<br /> |-<br /> ! ''modifier'' <br /> | aktuelle Tastenmodifizierer (siehe [[SDL_GetModState]])<br /> |-<br /> ! ''unicode'' <br /> | in Unicode übersetzter Buchstabe<br /> |}<br /> <br /> <br /> <br /> <br /> == Beschreibung == <br /> Enthält Informationen über die gedrückte Taste.<br /> <br /> <br /> <br /> <br /> == Hinweis ==<br /> Der Tastendruck wird nur in Unicode übersetzt wenn [[SDL_EnableUNICODE]] gesetzt wurde.<br /> <br /> == Siehe auch ==<br /> [[SDLKey]], [[SDLMod]]<br /> <br /> [[Kategorie:SDL|keysym]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Popping&diff=23951 2009-07-24T09:51:13Z

<p>Delphic: </p> <hr /> <div>&quot;Langsames Einblenden der Objekte mittels Blending.&quot;<br /> Das Zitat verlinkt direkt auf den Artikel Blending. Ich denke, daß die hier genannten Dinge zwar sehr ähnlich sind, aber ich glaube der Verweis ist für jemand der das nicht weis eher irreführend. Ich würde den Link entfernen und stattdessen einblenden schreiben - es handelt sich ja auch meistens um LOD. Vielleicht findet noch jemand einen besseren Begriff als ich, aber ich glaube, daß das Blending hier zwar rechnerisch sehr ähnlich ist, aber vom Effekt etwas völlig anderes beschreibt. ([[Benutzer:Delphic|Delphic]] 16:56, 24. Dez 2006 (CET))<br /> <br /> Wieso? Mann kann doch dentransparenzwert verändern. In verbindung mit villeicht glFog, könnte das Funktionieren. Oder nicht?<br /> LOD ist sicherlich die bessere Lösung.<br /> <br /> hmmm... ja. das kann sein. wenns ichs heute seh bin ich eh etwas verwirrt. trotzdem scheint mir der Artikel mit der Begrifflichkeit etwas seltsam zu sein, weil später einblenden für LOD kommt und das mitteln &quot;Blending&quot; verlinkt ist (Man kommt bei einem Artikel der sich Blenden nennt heraus). Da ist die Verwirrung dann ganz schnell perfekt, besonders wenn man vorher schon dem Blending einmal gefolgt ist und woanders herauskam.<br /> Vielleicht sollte man diese Zeile<br /> &quot;*Langsames Einblenden der neuen Detailstufe über die Alte mittels [[Blenden|Blending]].&quot;<br /> durch:<br /> *Langsames [[Blenden|Einblenden]] der neuen Detailstufe über die Alte.<br /> ersetzen. Dann wird man dadurch wohl nicht so irritiert, daß hier selbige Begriffe für unterschiedliches im Einsatz sind. ([[Benutzer:Delphic|Delphic]])</div>

Delphic https://wiki.delphigl.com/index.php?title=Archiv:tut_terrain2_exe&diff=23950 2009-07-24T09:49:58Z

<p>Delphic: </p> <hr /> <div>{{Archiv|autor=[[Benutzer:Delphic|Delphic]]|beschreibung=Windows 32 Binary zum [[Tutorial Terrain2]].}}</div>

Delphic https://wiki.delphigl.com/index.php?title=Archiv:tut_terrain2_src_vcl&diff=23949 2009-07-24T09:49:43Z

<p>Delphic: </p> <hr /> <div>{{Archiv|autor=[[Benutzer:Delphic|Delphic]]|beschreibung=Delphi-VLC-Quelltext zum [[Tutorial Terrain2]]|todo=Auf dglOpenGL.pas überarbeiten.}}</div>

Delphic https://wiki.delphigl.com/index.php?title=Archiv:tut_terrain1_src_vcl&diff=23948 2009-07-24T09:49:28Z

<p>Delphic: </p> <hr /> <div>{{Archiv|autor=[[Benutzer:Delphic|Delphic]]|beschreibung=Delphi-VLC-Quelltext zum [[Tutorial Terrain1]]|todo=Auf dglOpenGL.pas überarbeiten.}}</div>

Delphic https://wiki.delphigl.com/index.php?title=Archiv:tut_kameras_src_vcl&diff=23947 2009-07-24T09:49:13Z

<p>Delphic: </p> <hr /> <div>{{Archiv|autor=[[Benutzer:Delphic|Delphic]]|beschreibung=Delphi-VCL-Quelltext zum Programm vom [[Tutorial Kamera1]].|todo=Passende Geometry.pas muss gefunden und eingebunden werden, evtl. haben in der Geometry sich teilweise Bezeichner geändert.}}</div>

Delphic https://wiki.delphigl.com/index.php?title=Archiv:tut_kameras_exe&diff=23946 2009-07-24T09:48:52Z

<p>Delphic: </p> <hr /> <div>{{Archiv|autor=[[Benutzer:Delphic|Delphic]]|beschreibung=Programm (win32) zum Tutorial [[Tutorial Kamera1]].}}</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Raytracing&diff=23945 2009-07-24T09:48:31Z

<p>Delphic: </p> <hr /> <div>Schöne Bilder! Das mit den implizierten Körpern klingt interessant. Falls du da mal Lust (und Bilder) hast, kannst du das gern vertiefen. Auch in einem extra Artikel. Solche Artikel wie der hier, machen richtig was her! Ich schlag den mal als excellent vor. --[[Benutzer:Flash|Flash]] 08:36, 10. Dez. 2008 (UTC)<br /> <br /> Das ehrt mich. Ja kann mal ein bischen was darüber erzählen, wie man implizite Tracen kann, sobald Zeit dafür ist. Für einen exzellenten enthält diese Artikel aber etwas zu wenig Information, obwohl er natürlich sehr schön anzusehen ist :-) --[[Benutzer:Delphic|Delphic]] 17:17, 10. Dez. 2008 (UTC)<br /> <br /> OK, ich denke wir lassen ihn in der Wartestellung bis er Inhaltlich einen besseren Überblick über das Thema gibt.--[[Benutzer:Flash|Flash]] 17:56, 10. Dez. 2008 (UTC)</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Matrix&diff=23944 2009-07-24T09:48:17Z

<p>Delphic: </p> <hr /> <div>Bei der mxn-nxr-Matrix-Matrix Multiplikation ist ein Fehler: Bei dem Element unten links muss es nicht heißen &quot;3*7+0+1*4&quot; sondern &quot;3*5+0+4*7&quot;. Deshalb ist dann auch das Ergebnis 43 und nicht 25.<br /> Am besten wäre es sowieso, die gescannten Sachen durch schöne LaTeX-Formeln zu ersetzen. --[[Benutzer:Wilson|Wilson]] 15:26, 5. Dez. 2008 (UTC)<br /> <br /> Latex ist leider nicht automatisch möglich und wir müssten dafür eigene Bilder erstellen :(<br /> --[[Benutzer:I0n0s|I0n0s]] 22:48, 5. Dez. 2008 (UTC)<br /> <br /> Fehler bestätigt. Da ist wohl unserem Mathematiker mal ein Ausrutscher passiert. ;) --[[Benutzer:Flash|Flash]] 19:51, 6. Dez. 2008 (UTC)<br /> <br /> # Austrutscher? Wollte nur testen, ob auch alle aufpassen :-). Ich werde mich drum kümmern, evtl. wird sogar geTeXt... --[[Benutzer:Delphic|Delphic]] 22:44, 6. Dez. 2008 (UTC) <br /> # Erledigt. Schaut doch mal ob ich mich irgendwo vertan habe. --[[Benutzer:Delphic|Delphic]] 10:41, 7. Dez. 2008 (UTC)<br /> <br /> Sieht gut aus - sogar besser. Fehler konnte ich jetzt nicht sehen, aber als Beweis der Richtigkeit kann man das definitv nicht gelten lassen. ;) --[[Benutzer:Flash|Flash]] 14:49, 7. Dez. 2008 (UTC)<br /> <br /> Scheint in Ordnung zu sein.<br /> Um die &quot;Siehe Auch&quot;-Seiten kümmern sich dann doch hoffentlich Erst-Semester oder? ;-)<br /> <br /> --[[Benutzer:I0n0s|I0n0s]] 21:57, 7. Dez. 2008 (UTC)</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Farbraum&diff=23943 2009-07-24T09:47:48Z

<p>Delphic: </p> <hr /> <div>Die Bilder im Artikel werden nicht angezeigt<br /> Bei LAB könnte die Erklärung noch etwas umfangreicher ausfallen. Speziell auch der Zusammenhang wie man von einer bestimmten Wellenlänge auf die Farbe, oder bei einem schwarzen Körper auf seine seine Farbe (nein, nicht den wörtlichen, sondern den physikalischen mein ich ;-)) wäre hilfreich.<br /> <br /> Vergleiche auch folgenden Thread aus'm DF: http://www.delphi-forum.de/viewtopic.php?t=80668<br /> <br /> --[[Benutzer:BenBE|BenBE]] 02:50, 27. Feb. 2008 (CET)<br /> <br /> Oh Fehlen die Bilder schon wieder... Oder immernoch. Das Problem hatten wir jedenfalls schon einmal. Werde Flow mal wieder deswegen anhauen.<br /> <br /> Das mit LAB stell ich gerne jemand Anderes zur Verfügung - ich hab nur wenig Erfahrung in Sachen Farbechtheit und selbst auch nicht die nötige Hardware für sowas (Wenns mir jemand zur Verfügung stellt wärs evtl was anderes ;-) ). Da bin ich nicht sehr kompetent und bei meinen bisherigen Recherchen zu diesem Thema hab ich soweit nur festgestellt, daß gute Informationen wohl schiwerig zu haben sind. Einiges dazu gibts aber hier:<br /> http://www.color.org/<br /> <br /> [[Benutzer:Delphic|Delphic]] 17:56, 27. Feb. 2008 (CET)<br /> <br /> Ich hab mich mal um die Bilder gekümmert; War ziemlich ekelig alle Dateien im Wiki-Durcheinander wiederzufinden, aber jetzt sollte alles umbenannt sein und wieder funktionieren. Jemanden für LAB hab ich aber immer noch nicht aufgetrieben, nur festgestellt, daß fast niemand kalibrierte Monitore besitzt :-) --[[Benutzer:Delphic|Delphic]] 19:43, 9. Dez. 2008 (UTC)<br /> <br /> Wo hast du das eigentlich her mit den Personen die 4 Grundfarben sehen können? Es gibt doch nur 3 Rezeptoren. --[[Benutzer:Flash|Flash]] 17:00, 15. Dez. 2008 (UTC)<br /> <br /> Genetische Mutation... Hab das ursprünglich ausm Bio-Unterricht, hab aber auch etwas darüber wiedergefunden: http://en.wikipedia.org/wiki/Tetrachromacy#Possibility_of_human_tetrachromats --[[Benutzer:Delphic|Delphic]] 10:41, 16. Dez. 2008 (UTC)<br /> <br /> Interessant. Ich hab das im Artikel mal vermerkt. Quellen können durchaus nicht schaden. --[[Benutzer:Flash|Flash]] 13:09, 17. Dez. 2008 (UTC)</div>

Delphic https://wiki.delphigl.com/index.php?title=Datei_Diskussion:Tutorial_RaytracingI_strahlgleichung.png&diff=23942 2009-07-24T09:46:57Z

<p>Delphic: </p> <hr /> <div>Mathematisch korrekt ist die runde Klammer anstatt dem umgedrehten Eckigen.<br /> Daher bitte die alte Version wiederherstellen.<br /> <br /> Danke --[[Benutzer:I0n0s|I0n0s]] 22:20, 25. Dez 2006 (CET)<br /> <br /> Edit: Bäh, böser Cache. Habe die alte Version aus dem obigen Grund wiederhergestellt.<br /> <br /> --[[Benutzer:I0n0s|I0n0s]] 22:24, 25. Dez 2006 (CET)<br /> <br /> Was passiert mit diesem Bild? Also ich kenne den Ausschluss einer Elementes sowohl mit Runden, als auch mit umgedrehten Eckigen klammern. Das macht eigentlich jeder so wie ers mag... Ich hab mich an die Runden gewöhnt, drum ists ne runde geworden, aber so schrecklich wichtig ist das eigentlich nicht. Und gelgentlich ist es auch ganz nett, unendlich mit ins Intervall zu nehmen und die Reelen Zahlen abzuschließen. Allzuviel sind macht das hier allerdings nicht. ([[Benutzer:Delphic|Delphic]])<br /> <br /> Ich bin dafür, dass es mit den runden Klammer bleibt, daher auch das obige Chaos als ich versucht habe es wiederherzustellen und am Browsercache gescheitert bin :'(<br /> <br /> --[[Benutzer:I0n0s|I0n0s]] 14:59, 26. Dez 2006 (CET)</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Popping&diff=23941 2009-07-24T09:46:36Z

<p>Delphic: </p> <hr /> <div>&quot;Langsames Einblenden der Objekte mittels Blending.&quot;<br /> Das Zitat verlinkt direkt auf den Artikel Blending. Ich denke, daß die hier genannten Dinge zwar sehr ähnlich sind, aber ich glaube der Verweis ist für jemand der das nicht weis eher irreführend. Ich würde den Link entfernen und stattdessen einblenden schreiben - es handelt sich ja auch meistens um LOD. Vielleicht findet noch jemand einen besseren Begriff als ich, aber ich glaube, daß das Blending hier zwar rechnerisch sehr ähnlich ist, aber vom Effekt etwas völlig anderes beschreibt. ([[Benutzer:Delphic|Delphic]] 16:56, 24. Dez 2006 (CET))<br /> <br /> Wieso? Mann kann doch dentransparenzwert verändern. In verbindung mit villeicht glFog, könnte das Funktionieren. Oder nicht?<br /> LOD ist sicherlich die bessere Lösung.<br /> <br /> hmmm... ja. das kann sein. wenns ichs heute seh bin ich eh etwas verwirrt. trotzdem scheint mir der Artikel mit der Begrifflichkeit etwas seltsam zu sein, weil später einblenden für LOD kommt und das mitteln &quot;Blending&quot; verlinkt ist (Man kommt bei einem Artikel der sich Blenden nennt heraus). Da ist die Verwirrung dann ganz schnell perfekt, besonders wenn man vorher schon dem Blending einmal gefolgt ist und woanders herauskam.<br /> Vielleicht sollte man diese Zeile<br /> &quot;*Langsames Einblenden der neuen Detailstufe über die Alte mittels [[Blenden|Blending]].&quot;<br /> durch:<br /> *Langsames [[Blenden|Einblenden]] der neuen Detailstufe über die Alte.<br /> ersetzen. Dann wird man dadurch wohl nicht so irritiert, daß hier selbige Begriffe für unterschiedliches im Einsatz sind. ([[Benutzer:Nico Michaelis|Nico Michaelis]])</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Techniken_zur_Matrixinversion&diff=23940 2009-07-24T09:46:01Z

<p>Delphic: </p> <hr /> <div>Es wäre vieleicht noch toll, bei &quot;transponieren&quot; ein Beispiel zu machen.<br /> &lt;pre&gt;a1 a5 a9 a13 a1 a2 a3 a4<br /> a2 a6 a10 a14 --\ a5 a6 a7 a8<br /> a3 a7 a11 a15 --/ a9 a10 a11 a12<br /> a4 a8 a12 a16 a13 a14 a15 a16&lt;/pre&gt;<br /> <br /> Ich dachte eigentlich, daß Transposition sich eigentlich ganz gut so erklärt. In einer Tabelle zeilen mit Spalten zu vertauschen dürfte doch eigentlich klar sein? Allerdings ist imho Transposition selbst so wichtig, daß es ihr und ihren Eigenschaften in Bedarfsfall auch gerecht wird, ihr einen eigenen Artikel zu spendieren: da kann man dann gerne auch Beispiele bringen und es auch an Vektoren oder nichtquadratischen Matrizen zeigen, da sieht man dann auch etwas mehr - ob man allerdings in der 3D Grafik noch wesentlich mehr Anwendungen findet, als das invertieren von unitären Matrizen, da bin ich mir nicht so sicher - mir fällt zu dem thema jedenfalls nichts wesentliches ein.<br /> <br /> == Matrixinversion direkt mit OpenGL ==<br /> <br /> Mir fällt da noch eine ganz einfache Methode für die Berechnung der Matrixinverse ein ;)<br /> <br /> Hat man eine Modelview-Matrix setzt sich diese ja bekanntlich als Produkt verschiedener Matrizen mittels glRotate, glTranslate oder glScalef zusammen, also z.B. MV = ( A * B * C ).<br /> Für die Inverse gilt dann MV ^ -1 = ( A * B * C ) ^ -1.<br /> <br /> Bei der Matrizenmultiplikation gilt nun, dass sich bei der Auflösung der Klammer auf der rechten Seite die Matrizen vertauschen, also gilt dann :<br /> MV ^ -1 = C ^ -1 * B ^ -1 * A ^ -1.<br /> <br /> Man braucht also nur die Matrizenoperationen in umgekehrter Reihenfolge aufschreiben und die 'Inverse' nehmen.<br /> Das bedeutet z.B. dass man bei glTranslate( x, y, z ) als Inverse glTranslate( -x, -y, -z ) und bei glRotate( w, 1, 0, 0 ) als Inverse glRotate( -w, 1, 0, 0 ) nimmt, usw.<br /> <br /> Zum Schluss muß man sich die von OpenGL berechnete Matrix nur noch holen...<br /> <br /> Hier mal ein Code-Beispiel :<br /> <br /> &lt;pre&gt;<br /> //Speicher für Matrix<br /> float M_inv[16];<br /> <br /> glMatrixMode( GL_MODELVIEW );<br /> //Einheitsmatrix laden<br /> glLoadIdentity();<br /> <br /> //glRotate, glTranslate-Befehle in umgekehrter Reihenfolge und 'invertiert'<br /> <br /> //Matrix holen<br /> glGetFloatv( GL_TRANSPOSE_MODELVIEW_MATRIX, M_inv );&lt;/pre&gt;<br /> <br /> [[Benutzer:Dj3hut1|Dj3hut1]] 08:48, 10. Jan. 2009 (UTC)<br /> <br /> Ja das ginge schon, aber meistens hat man ja eher das Problem, dass man laengst nicht mehr rekonstruieren kann, wie die matrix entstand, weil recht viele iterationen von rotationen und translationen dahinter stehen und man ja gerade die matrix gespeichert hat, um sich das alles zu merken, die entstehungsdetails aber überflüssig sind. und transponieren ist schon ein sehr billiger vorgang, muss ja nicht einmal addieren oder multiplizieren dazu. <br /> [[Benutzer:Delphic|Delphic]] 09:52, 10. Jan. 2009 (UTC)</div>

Delphic https://wiki.delphigl.com/index.php?title=Diskussion:Tutorial_Texturgenerator&diff=23939 2009-07-24T09:45:30Z

<p>Delphic: </p> <hr /> <div>Ich denke, wir koennen das gute Stueck mal entsorgen? Da hat sich schon lang nix mehr getan und antworten tut Red ja scheints auch nicht? Muesste aber jemand mit den entsprechenden Rechten tun.<br /> <br /> [[Benutzer:Delphic|Delphic]] 15:12, 13. Dez 2006 (CET)<br /> <br /> Tut scheint tod zu sein. Was damit machen?<br /> <br /> --[[Benutzer:I0n0s|I0n0s]] 14:40, 30. Apr 2006 (CEST)<br /> <br /> <br /> Ich schreib Red nochmal an.<br /> <br /> --[[Benutzer:Flash|Flash]] 18:05, 30. Apr 2006 (CEST)</div>

Delphic https://wiki.delphigl.com/index.php?title=Kategorie_Diskussion:Exzellent&diff=23938 2009-07-24T09:44:55Z

<p>Delphic: </p> <hr /> <div>=Voraussetzungen für Exzellente Artikel=<br /> Hier könnt ihr Artikel vorschlagen welche ihr als &quot;exzellenten Artikel&quot; einstufen würdet.<br /> <br /> Folgende Punkte '''müssen''' erfüllt sein:<br /> * Kein Sackgassenartikel - Artikel muss auf andere Artikel direkt (nicht über Code) verlinken<br /> * Kein Plain Text - Artikel muss eine einheitliche Formatierung aufweisen<br /> * Bilder - Artikel muss mindestens ein Bild/Grafik besitzen<br /> * Umfassend - Der Artikel muss das Thema umfassend behandeln.<br /> * Kein Tutorial - Der Artikel darf nicht der [[:Kategorie:Tutorial|Kategorie Tutorial]] angehören.<br /> <br /> <br /> Damit ein Artikel als '''exzellent''' eingestuft wird müssen:<br /> * 3 Wiki-User der Wahl zustimmen darunter mindestens ein Moderator,<br /> * keine Gegenstimmen bestehen,<br /> * die Voraussetzungen von oben gelten.<br /> <br /> &lt;br&gt;<br /> <br /> =Kandidatenliste=<br /> Um einen Artikel zur Kandidatenliste hinzuzufügen bitte den Nachfolgenden Code vor dem Ende (&quot;&lt;nowiki&gt;|}&lt;/nowiki&gt;&quot;) der Tabelle einfügen:<br /> <br /> |&lt;nowiki&gt;[[Artikelname]]&lt;/nowiki&gt;<br /> |<br /> |<br /> |<br /> |-<br /> <br /> Um eine Stimme abzugeben, kopiert ihr bitte den Wiki-Code &quot;&lt;nowiki&gt;--~~~~&lt;/nowiki&gt;&quot; in die entsprechende Spalte. Das Wiki generiert daraus eure Unterschrift (Signatur).<br /> <br /> Falls ihr eine Gegenstimme abgebt, muss eine Begründung dazu gegeben werden.<br /> <br /> ----<br /> &lt;br&gt;<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}}<br /> !width=&quot;15%&quot;|Vorgeschlagener Artikel<br /> !width=&quot;20%&quot;|Beführworter<br /> !width=&quot;20%&quot;|Gegner<br /> !width=&quot;45%&quot;|Begründung für Gegenstimme / Diskussion<br /> |-<br /> | [[glTexParameter]]<br /> | <br /> | --[[Benutzer:Flash|Flash]] 09:56, 11. Jan 2007 (CET)<br /> |Wenn jemand noch die restlichen Wrapmodes einbaut sicher ein guter kandidat (GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER,GL_MIRRORED_REPEAT laut glitmap.pas) (Winner)<br /> <br /> Stimme Winner zu. Ohne die ergänzungen kommt der Artikel nicht in Frage.<br /> |-<br /> |[[gluCylinder]]<br /> | --[[Benutzer:Flash|Flash]] 09:09, 10. Apr. 2008 (UTC)<br /> | <br /> | <br /> |-<br /> |[[Raytracing]]<br /> | <br /> | --[[Benutzer:I0n0s|I0n0s]] 13:25, 10. Dez. 2008 (UTC)<br /> --[[Benutzer:Delphic|Delphic]] 17:14, 10. Dez. 2008 (UTC)<br /> |<br /> # Es existieren 2 Tutorials zu dem Thema.<br /> # Ist nur als Oberflächliche Information konzipiert und enthält keine Information, wie die Techniken tatsächlich zu verwenden sind.<br /> <br /> Ok. Bis der Artikel das Thema etwas besser &quot;ausleuchtet&quot; ;) bleibt das Veto stehen. Die Tutorials sprechen nicht dagegen. --[[Benutzer:Flash|Flash]] 17:58, 10. Dez. 2008 (UTC)<br /> |-<br /> |}<br /> &lt;/div&gt;<br /> <br /> <br /> &lt;br&gt;<br /> &lt;br&gt;<br /> &lt;br&gt;<br /> &lt;br&gt;<br /> <br /> == Auswahlkriterien ==<br /> <br /> Ich finde die Asuwahlkriterien etwas strange. Schließlich sind Tutorials auch Artikel und in den meisten Fällen noch dazu ziemlich gute. Warum sollten diese also ausgeschlossen werden? Vermitteln ja schließlich meist recht anschaulich viel Information. Also exakt das, was nen guten Artikel ausmacht.<br /> --[[Benutzer:Frase|Frase]] 18:48, 18. Mär 2006 (CET)<br /> <br /> <br /> Tutorials sind einzelarbeiten die von einer Person gemacht wurden und die eigentlich auch nur von dieser zu Verantworten/Verbessern sind. Die Auszeichnung soll gerade dafür sorgen die &quot;graue Maus&quot; Artikel aufzuwerten. Das unsere Tutorials alle Exzellent sind steht außer Frage. Die Auszeichnung heißt aber nicht um sonst &quot;Exzellente Artikel&quot; und nicht &quot;Exzellente Tutorials&quot;. Außerdem soll die Auzeichnung erreichen, dass die Nutzer einfach mal ins Wiki reinlesen. Tutorials sind in sich geschlossen und verlinken kaum auf andere Artikel. Sie behandeln ein Thema, und das ist gut so.<br /> --[[Benutzer:Flash|Flash]] 01:11, 19. Mär 2006 (CET)<br /> <br /> <br /> Und es kann die Leute animieren die Artikel den Kritierie anzupassen bzw. eigene Artikel einzustellen.<br /> So hat es zumindest bei mir funktioniert. Ich habe jetzt sogar Bilder! :lol:<br /> <br /> --[[Benutzer:I0n0s|I0n0s]] 04:35, 19. Mär 2006 (CET)</div>

Delphic https://wiki.delphigl.com/index.php?title=Datei:Frustum.jpg&diff=23937 2009-07-24T09:43:40Z

<p>Delphic: </p> <hr /> <div>Frustum-Handzeichnung<br /> <br /> Zeichner: Delphic&lt;br&gt;<br /> Datum: 10. September 04</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Raytracing_-_Grundlagen_II&diff=23934 2009-07-23T15:12:22Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>= Raytracing Grundlagen II =<br /> [[Bild:Tutorial_RaytracingI_teaser.jpg|center]]<br /> == Einführung ==<br /> Und weiter geht es mit unsem Raytracing Tutorial. Wir wollen unseren Raytracer nun langsam aber sicher soweit bekommen, daß sich damit etwas ansehnlichere Bilder erzeugen lassen. Wer das [[Tutorial_Raytracing_-_Grundlagen_I|vorangehende Tutorial]] nicht gelesen hat, sollte dies am besten gleich tun - ich will ja nicht alles neu erklären. Womit werden wir uns denn heute beschäftigen? Zuerst werden wir ein erweiterbares Objektmodell für alle Objekte planen und überlegen. Dann wollen wir uns ein wenig mit Phong-Lighting beschäftigen und einige Gedanken in Richtung Transformationen verschwenden. Mit diesem Plan sind wir, so denke ich, erstmal gut beschäftigt.<br /> <br /> == Ein schönes Basisobjekt ==<br /> Wir wollen die Objekte in unsem Raytracer möglichst gleich behandeln können, so daß der eigentliche Raytracing Algorithmus ohne jegliches wissen über die Struktur der Objekte arbeiten kann. Sprich: Wir definieren ein Basisobjekt, von dem anschließend alle weiteren Objekte abgeleitet werden. Was also soll dieses Objekt an Methoden und Eigenschaften zur Verfügung stellen? Jedes Objekt hat sicherlich eine Position, sowie gewissen Materialeigenschaften, die dem Objekt zugewiesen werden. Auch soll das Objekt sauber mit Transformationen umgehen können. Und was natürlich ganz wichtig ist: Wir brauchen eine Methode die prüft, ob sich das Objekt mit dem Strahl schneidet. Über einige dieser Dinge haben wir uns noch keine Gedanken gemacht, entsprechend sollen hierfür nur leere Dummyklassen und Methoden zum Einsatz kommen, die wir erst später realisieren. Damit es nicht vergessen wird: Es ist auch sinnvoll Vater-Kindbeziehungen zu haben um später zusammengesetzte Objekte definieren zu können. Das klingt alles etwas wild, artet in einer großen Menge Code aus, ist aber eigentlich gar nicht so schlimm, wei es sich anhört:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt; /// General Raytracing object in a tracer. All traceable objects must be derivates<br /> public abstract class ObjectBase<br /> {<br /> #region Positioning Variables<br /> <br /> private Vertex3 pos = new Vertex3();<br /> /// The Position of the Object in parental Space<br /> public Vertex3 Position<br /> {<br /> get { return pos; }<br /> set { pos = value; /*InvalidateBoundings(true);*/ }<br /> // Anm.: InvalidateBoundings brauchen wir jetzt noch <br /> // nicht. Wenn man allerdings mit Bounding-Volumes<br /> // zu arbeiten beginnt, wird man entsprechende<br /> // Funktionalität benötigen. Vorerst gilt: Forget it.<br /> }<br /> <br /> private ILinearTransformation ptransformation;<br /> /// The Transformation applied to the object<br /> public ILinearTransformation Transformation<br /> {<br /> get<br /> {<br /> return ptransformation;<br /> }<br /> set<br /> {<br /> ptransformation = value;<br /> //InvalidateBoundigs(true);<br /> }<br /> }<br /> #endregion<br /> <br /> #region Material<br /> private Material objMaterial = new StandardMaterial();<br /> /// Material assigned to object<br /> public Material ObjectMaterial<br /> {<br /> ...<br /> }<br /> #endregion<br /> <br /> #region Parenting<br /> // The parental object<br /> private ObjectBase fParent;<br /> <br /> /// The Parent of the object<br /> public ObjectBase Parent<br /> {<br /> ...<br /> }<br /> #endregion<br /> <br /> #region Trans Space Functions<br /> public virtual Vertex3 TransSpaceWorldToObject(Vertex3 v) {...}<br /> public virtual Ray TransSpaceWorldToObject(Ray r) {...}<br /> public virtual Vertex3 TransSpacePointWorldToObject(Vertex3 v) {...}<br /> public virtual Vertex3 TransSpacePointParentToObject(Vertex3 v) {...}<br /> public virtual Ray TransSpaceParentToObject(Ray r) <br /> {<br /> Ray ray = r;<br /> ray.o -= pos;<br /> return ray;<br /> }<br /> public virtual Vertex3 TransSpaceParentToObject(Vertex3 v) {...}<br /> public virtual Vertex3 TransSpaceObjectToWorld(Vertex3 v) {...}<br /> public virtual Vertex3 TransSpacePointObjectToWorld(Vertex3 v) {...}<br /> #endregion<br /> <br /> #region Intersection Tests<br /> /// Calculates the first visible intersection. Returns values smaller<br /> /// equal zero if there is no intersection. <br /> /// param name=&quot;rs&quot;: Global rendersettings<br /> /// param name=&quot;ray&quot;: the ray to test for intersection<br /> /// param name=&quot;raymindist&quot;:<br /> /// param name=&quot;raymaxdist&quot;:<br /> /// param name=&quot;calcNormals&quot;:<br /> /// param name=&quot;calcTextureCoordinates&quot;:<br /> /// param name=&quot;info&quot;:<br /> public abstract int Intersect(RenderSettings rs, Ray ray, double raymindist, double raymaxdist,<br /> bool calcNormals, bool calcTextureCoordinates, ref IntersectionInfo info);<br /> #endregion<br /> } <br /> &lt;/source&gt;<br /> Das schaut jetzt tatsächlich etwas wild aus, aber keine Angst. Wir werden das alles der Reihe nach mit Leben füllen. Die Trans-Space-Funktionen werden wir anschließend mit Leben füllen - nur TransSpaceParentToObject kann gleich bestückt werden (wir werden das aber später erweitern müssen). Sie soll Strahlen aus dem Eltern-Raum in den lokalen Raum überführen - für die meisten Objekte bedeutet dies: Die globalen Koordinaten werden in lokale übersetzt, so daß sich unser Objekt genau im Zentrum des Geschehens, d.h. bei (0,0,0), befindet und wir uns dann nie wieder über die Position des Objektes Gedanken machen müssen.<br /> <br /> Einen Blick sind auch die Parameter von Intersect wert. rs beschreibt globale Einstellungen des Renderers. Darin könnte man z.B. festlegen, ob Schatten berechnet werden sollen oder nicht. Ihr könnt hier im wesentlichen spazieren führen was ihr wollt, aber diese Option zu haben ist jedenfalls nicht verkehrt. ray dürfte klar sein.<br /> Dies wird ein Strahl sein, der jeweils in elterlichen Koordinaten gegeben ist, also mithilfe von TransSpaceParentToObject in lokale Koordinaten umgerechnet werden kann. raymindist und raymaxdist beschreiben jeweils Bereich des Strahles, in dem wir nach Überschneidungen suchen sollen - haben wir es mit einem numerisch zu berechnenden Objekt zu tun, kann diese Information bereits sehr viel Geschwindigkeit ausmachen. Beim Schnitt mit Kugeln ist die Sache dagegen weniger wichtig. Essenziell ist, daß beim Aufruf von Intersect sichergestellt sein muss, daß nur dann positive Rückmeldung gemacht wird, wenn die Überschneidung an einer Stelle des Strahles zu finden ist, die größer gleich raymindist ist: Darauf sollte man sich verlassen können. calcNormals und calcTextureCoordinates beschreibt, ob beim Überschneidungstest Informationen über Flächennormalen bzw. Texturkoordinaten erzeugt werden sollen: Bei manchen Objekten ist auch diese Information nur kostspielig zu bekommen und wir wollen es deshalb optional halten. Es bleibt noch der Call by Reference Parameter info. Darin sollen genauere Informationen bezüglich des Schnittes gespeichert werden - etwa lokale Farben, Material, Texturkoordinaten, Schnittposition, etc. (Die Schnittposition könnte man auch direkt zurückgeben, also den Rückgabewert durch einen Float-Typ wie double ersetzen. Seis drum)<br /> <br /> Noch schnell ein kleiner Blick in eine mögliche Definition der IntersectionInfo. Darin befindet sich nichts anderes, als wie das, was ich gerade beschrieben habe. Also keine Überraschungen ;-)<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt; public struct IntersectionInfo<br /> {<br /> /// Position on ray where the cut occured<br /> public double rayPosition;<br /> /// Normal of surface at cut position<br /> public Vertex3 normal;<br /> /// Texture coordinates<br /> public Vertex3 texture;<br /> /// Material of surface at intersection position<br /> public Material material;<br /> /// The local color of the intersection. This must be optional<br /> /// for all materials!!! Some Objects may always return black here.<br /> public Color localColor;<br /> }<br /> &lt;/source&gt;<br /> <br /> == Transformationen ==<br /> Wir wollen uns nun um Transformationen kümmern. Was also sind Transformationen? Wer mit OpenGl vertraut ist, kennt sie sie ganz gut: Es handelt sich um genau das, was man mit den Funktionen [[glTranslate]], [[glRotate]], [[glScale]], usw. bewirken kann. Verschiebungen haben wir bereits durch die Position des Objektes abgehakt, wir können uns hier also auf Dinge wie Scheerungen, Rotationen usw. beschränken. Wer Nachholbedarf in diesen Themen hat, der sollte sich jetzt hier darum kümmern, dieses Defizit etwas zu mildern. Da DelphiGl aber schon eine Weile existiert, finden sich fast alle nötigen Informationen in Tutorias oder Wiki-Artikeln: [[Matrix]],<br /> [[Tutorial_Nachsitzen|Nachsitzen]], [[Tutorial_Matrix2|Matrix 2]], [[Quaternion]]. Auch die Wikipedia ist hier in der [http://de.wikipedia.org/wiki/Kategorie:Lineare_Algebra Kategorie Lineare Algebra] gut ausgestattet, um weitere Informationen einzuholen.<br /> Wer hoch in den Code des Basis-Objektes schaut, dem wird auffallen, daß Transformationen durch das Interface ILinearTransformation definiert sind:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;<br /> /// Defines a linear Trafo<br /> public interface ILinearTransformation<br /> {<br /> /// Applys the Trafo to v<br /> Vertex3 Apply(Vertex3 v);<br /> /// Applys the inverse Trafo to v<br /> Vertex3 ApplyInverse(Vertex3 v);<br /> <br /> /// Conversion of the Trafo to Matrix3x3<br /> Matrix3x3 ConvertTo3x3();<br /> /// Conversion of the Inverse Trafo to Matrix3x3 <br /> Matrix3x3 ConvertInverseTo3x3();<br /> <br /> /// Right Mulltiplication of factor with this to a new, returned ILinearTransformation.<br /> /// Probably the trafos are converted to a LinearTransformationMatrix, but if both<br /> /// trafos are of the same type, its a good idea to multiply them together.<br /> ILinearTransformation MultiplyWithLinear(ILinearTransformation factor);<br /> }<br /> &lt;/source&gt;<br /> <br /> So kann man ohne weiteres Quaternionen und Matrizen wild nebeneinander verwenden. Mit der Methode MultiplyWithLinear kann man dann auch verschiedene Multiplikationen miteinander verknüpfen. So kann man Quaternionen einfach mit Quaternionen multiplizieren und gemischtes, wenn etwa Quaternionen mit Matrizen multipliziert werden, in Matrizen umwandeln:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;<br /> #region ILinearTransformation Members<br /> <br /> /// Rotates a Vertex3 through the Quaternion - this should be normalized!<br /> public Vertex3 Apply(Vertex3 v) {...}<br /> /// Rotates a Vertex3 against the Quaternion. A normalized Quaternion is assumed!<br /> public Vertex3 ApplyInverse(Vertex3 v) {...}<br /> <br /> /// Converts the Quaternion to a 3x3 Matrix<br /> public Matrix3x3 ConvertTo3x3()<br /> {<br /> Matrix3x3 result = new Matrix3x3();<br /> result.sp0 = Apply(new Vertex3(1.0, 0.0, 0.0));<br /> result.sp1 = Apply(new Vertex3(0.0, 1.0, 0.0));<br /> result.sp2 = Apply(new Vertex3(0.0, 0.0, 1.0));<br /> return result;<br /> }<br /> <br /> /// Converts the Inverse Quaternion to a 3x3 Matrix<br /> public Matrix3x3 ConvertInverseTo3x3()<br /> {<br /> Matrix3x3 result = new Matrix3x3();<br /> result.sp0 = ApplyInverse(new Vertex3(1.0, 0.0, 0.0));<br /> result.sp1 = ApplyInverse(new Vertex3(0.0, 1.0, 0.0));<br /> result.sp2 = ApplyInverse(new Vertex3(0.0, 0.0, 1.0));<br /> return result;<br /> }<br /> <br /> /// Multiply the Quaternion with another trafo. If its a Quaternion, this and factor<br /> /// will be multiplied together, otherwise a LinearTransformationMatrix is generated.<br /> public ILinearTransformation MultiplyWithLinear(ILinearTransformation factor)<br /> {<br /> if (factor == null) return this;<br /> Quaternion fac = factor as Quaternion;<br /> if (fac != null)<br /> {<br /> return Multiply(fac);<br /> }<br /> else<br /> {<br /> // factor is not wenn known to us, we need a new LinearTransformationMatrix<br /> Matrix3x3 lin = ConvertTo3x3() * factor.ConvertTo3x3();<br /> Matrix3x3 inv = factor.ConvertInverseTo3x3() * ConvertInverseTo3x3();<br /> return new LinearTransformationMatrix(lin, inv, factor.Operator2Norm() * Operator2Norm());<br /> }<br /> }<br /> #endregion<br /> &lt;/source&gt;<br /> An diesem Beispiel aus meinem Quaternioncode kann man folgendes sehen: Die Funktionen ConvertTo3x3 und ConvertInverseTo3x3 berechnen jeweils die zum Quaternion gehörenden, äquivalenten Matrizen ( Man erinnere sich an den Satz, den ich bereits im Nachhilfe Tutorial zitiert habe: Die Spalten sp&lt;sub&gt;i&lt;/sub&gt; der Matrix sind die Bilder der Einheitsvektoren. Dann dürfte sofort klar sein, was hier passiert ). In MultiplyWithLinear wird dann einfach geprüft, ob die Transformation mit der rechts multipliziert wird, ein Quaternion ist. Dann wird einfach Quaternion-Multiplikation durchgeführt, ansonsten werden sowohl der Faktor als auch das betrachtete Quaternion in 3x3 Matrizen umgewandelt und in einer LinearTransformationMatrix abgelegt - welches natürlich ILinearTransformation implementiert und immer die Transformationsmatrix und ihr Inverses bereithält.<br /> <br /> Damit ihr nicht ewig rumrechnen müsst (es handelt sich nämlich um eine schrecklich langwierige und ekelige Rechnerei: Ich habe etwa 2 Stunden gebraucht, bis das Ergebnis endlich fehlerfrei und brauchbar auf 2 DIN-A4 Blättern verteilt da stand), wenn ihr Quaternionen implementiert noch ein paar kleine Methoden des Quaternions. Den Rest werdet ihr dann wohl aus dem [[Quaternion|Quaternionen-Artikel]] selbst in kurzer Zeit zusammenstöpseln können.<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt; // &quot;Coordinates&quot; of the Quaternion. <br /> // coords[0] is the real component, coords[1] the i comp., ...<br /> private double[] coords = new double[4];<br /> <br /> /// Creates a rotation Quaternion<br /> public Quaternion(double alpha, Vertex3 rotAxis)<br /> {<br /> alpha = (2.0*Math.PI/(360.0*2.0))* alpha;<br /> <br /> coords[0] = 1.0;<br /> if (rotAxis.Magnitude &lt; double.Epsilon)<br /> {<br /> return;<br /> }<br /> <br /> rotAxis.Normalize();<br /> double c, s;<br /> c = Math.Cos(alpha); s = Math.Sin(alpha);<br /> coords[0] = c; coords[1] = rotAxis[0] * s; <br /> coords[2] = rotAxis[1] * s; coords[3] = rotAxis[2] * s;<br /> }<br /> <br /> /// Rotates a Vertex3 through the Quaternion - this should be normalized!<br /> public Vertex3 Apply(Vertex3 v)<br /> {<br /> Vertex3 result = new Vertex3();<br /> double v0 = v[0]; double v1 = v[1]; double v2 = v[2];<br /> double a00 = coords[0] * coords[0];<br /> double a01 = coords[0] * coords[1];<br /> double a02 = coords[0] * coords[2];<br /> double a03 = coords[0] * coords[3];<br /> double a11 = coords[1] * coords[1];<br /> double a12 = coords[1] * coords[2];<br /> double a13 = coords[1] * coords[3];<br /> double a22 = coords[2] * coords[2];<br /> double a23 = coords[2] * coords[3];<br /> double a33 = coords[3] * coords[3];<br /> result[0] = v0 * (+a00 + a11 - a22 - a33)<br /> + 2 * (a12 * v1 + a13 * v2 + a02 * v2 - a03 * v1);<br /> result[1] = v1 * (+a00 - a11 + a22 - a33)<br /> + 2 * (a12 * v0 + a23 * v2 + a03 * v0 - a01 * v2);<br /> result[2] = v2 * (+a00 - a11 - a22 + a33)<br /> + 2 * (a13 * v0 + a23 * v1 - a02 * v0 + a01 * v1);<br /> return result;<br /> }<br /> /// Rotates a Vertex3 against the Quaternion. A normalized Quaternion is assumed!<br /> public Vertex3 ApplyInverse(Vertex3 v)<br /> {<br /> Vertex3 result = new Vertex3();<br /> double v0 = v[0];<br /> double v1 = v[1];<br /> double v2 = v[2];<br /> // Like Apply. We only konjugate the im. factors<br /> double a00 = coords[0] * coords[0];<br /> double a01 = -coords[0] * coords[1];<br /> double a02 = -coords[0] * coords[2];<br /> double a03 = -coords[0] * coords[3];<br /> double a11 = +coords[1] * coords[1];<br /> double a12 = +coords[1] * coords[2];<br /> double a13 = +coords[1] * coords[3];<br /> double a22 = +coords[2] * coords[2];<br /> double a23 = +coords[2] * coords[3];<br /> double a33 = +coords[3] * coords[3];<br /> result[0] = v0 * (+a00 + a11 - a22 - a33)<br /> + 2 * (a12 * v1 + a13 * v2 + a02 * v2 - a03 * v1);<br /> result[1] = v1 * (+a00 - a11 + a22 - a33) <br /> + 2 * (a12 * v0 + a23 * v2 + a03 * v0 - a01 * v2);<br /> result[2] = v2 * (+a00 - a11 - a22 + a33) <br /> + 2 * (a13 * v0 + a23 * v1 - a02 * v0 + a01 * v1);<br /> return result;<br /> }<br /> &lt;/source&gt;<br /> Wer ein Quaternion mithilfe des angegebenen Konstruktors erstellt, erhält ein Rotationsquaternion der Norm 1. Genau das, was für die Funktionen Apply und ApplyInverse notwendig ist, damit sie das tun, was sie sollen. Damit soll ersteinmal der Faulheit beim Rechnen und dem Copy&amp;Paste genüge getan sein. Und wehe ich entdecke irgendwann Raytracer, die Objekte nur rotieren können statt beliebige [[Matrix|Matrizen]] zu vertragen ;-) Am Ende bleibt es natürlich euch überlassen. Wenn ihr wollt, könnt ihr all das auch allein durch Matrizen implementieren und euch den Umweg über das Quaternion ersparen - allerdings sieht man einem Quaternion schneller an was es bewirkt, als einer Matrix.<br /> <br /> Nachdem wir einen kleinen Ausflug in Richtung Quaternionen und Transformationen hinter uns gebracht haben, könnte man hoffen, daß wir jetzt endlich mit dem abstrakten Kram aufhören und wir bald mal wieder ein paar neue Bilder zu Gesicht bekommen. Soweit ist es leider noch nicht. Ich möchte zwischendrin den Schlachtplan für die nächsten Minuten bekannt geben: Wir werden jetzt die Punkte in den Trans-Space-Funktionen der Basisklasse füllen, um uns dann dem Licht durch Phong-Lighting über den Umweg der Normalen zu widmen. Beginnen wir also mit der Funktion TransSpaceParentToObject, welche Strahlen des elterlichen Raumes in den lokalen Raum transformieren soll. Wenn man nun an die Kameraanalogie denkt, wie sie etwa im [[Tutorial_Kamera1|Kamera Tutorial]] beschrieben ist, dann wissen wir, daß wir die auf das Objekt angewendete Transformation einfach nur umkehren müssen. Denkt man dann noch daran, daß wir erreichen wollen, daß das Objekt im lokalen Raum am Ursprung befinden soll, ist die Implementation schnell naheliegend: Den Ursprung des Strahles müssen wir erst um die Position verschieben und dann invers transformieren. Bei der Richtung genügt es, diese invers zu transformieren.<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;<br /> public virtual Ray TransSpaceParentToObject(Ray r)<br /> {<br /> Ray ray = r;<br /> ray.Origin -= pos;<br /> if (ptransformation != null)<br /> {<br /> ray.Origin = ptransformation.ApplyInverse(ray.Origin);<br /> ray.Direction = ptransformation.ApplyInverse(ray.Direction);<br /> }<br /> return ray;<br /> }<br /> &lt;/source&gt;<br /> Bei dieser Überlegung fallen auch gleich die Funktionen TransSpacePointParentToObject, welche einen Punkt in die lokalen Koordinaten überträgt und die Entsprechende Funktion TransSpaceParentToObject für Richtungen ab. Das ganze können wir natürlich auch in die andere Richtung machen: Bislang ist mir aber noch kein Grund eingefallen, dies zu tun. Wichtig dagegen ist es, Richtungen in Weltkoordinaten umzurechnen, da wir dies für die Normalen später benötigen werden. Dies erreichen wir leicht, wenn wir ausnutzen, daß Objekte immer ihre Eltern kennen:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt; public virtual Vertex3 TransSpaceObjectToWorld(Vertex3 v)<br /> {<br /> if (ptransformation != null)<br /> {<br /> v = ptransformation.Apply(v);<br /> }<br /> if (fParent != null)<br /> {<br /> v = fParent.TransSpaceObjectToWorld(v);<br /> }<br /> return v;<br /> }<br /> &lt;/source&gt;<br /> Die entsprechende Funktion für Punkte solltet ihr der Übung halber selbst schreiben. Mit den genannten Zweien kommen wir auf jeden Fall erst einmal aus - ich bin mir gar nicht sicher, ob in meinem eigenen Raytracer je die Anderen zum Einsatz gekommen sind. Naja, es schadet jedenfalls nicht, wenn sie da sind.<br /> <br /> [[Bild:Tutorial_RaytracingII_spherenormals.jpg|right|framed|Visualisierung der Normalen]]<br /> Um nun mit dem Licht weiter machen zu können, müssen wir die Intersect-Funktionen für Kugeln und Ebenen um Normalenerzeugung erweitern. Wir dürfen nicht vergessen, diese dann in den World-Space zu transformieren:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt; /// Calculates the World-Space normal for a surface point<br /> protected Vertex3 CalcNormal(Vertex3 v)<br /> {<br /> Vertex3 normal = TransSpaceObjectToWorld(v);<br /> normal.Normalize();<br /> return normal;<br /> }<br /> ...<br /> public override int Intersect(RenderSettings rs, Ray ray, <br /> double raymindist, double raymaxdist, bool calcNormals, <br /> bool calcTextureCoordinates, ref IntersectionInfo info)<br /> {<br /> Ray osray = TransSpaceParentToObject(ray);<br /> <br /> double a, b, c;<br /> a = osray.d.DotDot; b = 2 * (osray.o * osray.d);<br /> c = osray.o.DotDot - sphereRadius * sphereRadius;<br /> <br /> double t1, t2;<br /> int roots = GeoMath.CalcQuadricRoots(a, b, c, out t1, out t2);<br /> <br /> // roots are sorted so check only for tr2<br /> if (roots &gt; 0 &amp;&amp; t2 &gt;= raymindist &amp;&amp; t1 &lt;= raymaxdist)<br /> {<br /> info = new IntersectionInfo();<br /> Vertex3 v; info.material = ObjectMaterial;<br /> <br /> info.rayPosition = t1;<br /> if (t1 &gt;= raymindist)<br /> {<br /> v = osray.Evaluate(t1);<br /> if (calcNormals) info.normal = CalcNormal(v);<br /> if (calcTextureCoordinates) <br /> info.texture = GeoMath.SphereCoordinates(v);<br /> return 1;<br /> }<br /> <br /> v = osray.Evaluate(t2);<br /> if (calcNormals) info.normal = CalcNormal(v);<br /> if (calcTextureCoordinates) <br /> info.texture = GeoMath.SphereCoordinates(v);<br /> info.rayPosition = t2;<br /> return 1;<br /> }<br /> else<br /> return -1;<br /> }<br /> &lt;/source&gt;<br /> <br /> == Phong Licht ==<br /> [[Bild:Tutorial_RaytracingII_phong.jpg|center]]<br /> <br /> Wir sind soweit. Die ersten hübscheren Bilder aus unserem Raytracer sind greifbar nahe. Wir müssen uns im wesentlichen nur noch mit Phong Licht beschäftigen, um aus unserem Raytracer mehr herauszuquetschen. Das Phong-Beleuchtungsmodell ist ein sehr einfaches Modell, um Licht zu simulieren. Es ist physikalisch ziemlich falsch: Durch Hinzufügen von Objekten in einen physikalischen Raum, die sich lichttechnisch nach dem Phong Modell verhalten, wird i.A. die vorhandene Lichtenergie erhöht. Das ist sehr tragisch, wenn man globale Beleuchtungsmethoden verwendet, aber fürs erste ist es ein sehr gut aussehendes und leicht zu berechnendes Modell. Wir wollen uns also von dieser Anomalität nicht beunruhigen lassen und uns nur daran erinnern, wenn wir einmal globale Beleuchtungsmethoden einführen wollen. Jedem sollte das Phong Modell wohl vertraut sein, da es das Standard-Modell in OpenGl ist. Wer hier noch Nachholbedarf hat, schaue doch einmal im [[Beleuchtung|Beleuchtungs-Artikel]] oder [http://www.delphi3d.net/articles/viewarticle.php?article=phong.htm in Tom Nuydens': Phong For Dummies]. <br /> <br /> Jedenfalls, wenn wir jedem Objekt ein Material mit den Koeffizienten aus dem Phong-Modell zugeordnet haben, dann können wir mithilfe einer IntersectionInfo für Strahl/Objekt-Schnittpunkte und aller Lichtquellen leicht die zugehörige Farbe bestimmen. An der Stelle, wo wir also im Tiefentracer den Grauwert bestimmten, bestimmen wir<br /> jetzt den zugehörigen Farbwert über unser Material: <br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;public RaytraceImage ( int width , int height )<br /> {<br /> for ( int x = 0; x &lt; width; x++) {<br /> for ( int y = 0 ; y &lt; height; y++) {<br /> Ray shoot = ShootRay (x , y);<br /> double maxdist = double.Infinity;<br /> <br /> IntersectionInfo cinfo = new IntersectionInfo();;<br /> IntersectionInfo iinfo = new IntersectionInfo();<br /> <br /> foreach (ObjectBase obj in SichtbareObjekte) {<br /> if (obj.Intersect(rs, shoot, 0, maxdist, true, true, ref cinfo) &gt; 0 <br /> &amp;&amp; cinfo.rayPosition &lt; maxdist) iinfo = cinfo;<br /> }<br /> <br /> if (maxdist &lt; double.Infinity &amp;&amp; iinfo.material != null) {<br /> SetColor(x, y, iinfo.Material.GetColor(iinfo));<br /> }<br /> else<br /> SetColor(x, y, BackgroundColor); <br /> }<br /> }<br /> }<br /> &lt;/source&gt;<br /> <br /> == Abschluss ==<br /> Da habt ihr euch ja durch ein dickes Ding gequält ( besonders wenn ihr im Bereich Transformationen oder Phong noch Nachholbedarf hattet, hats sicher eine Weile gedauert ). Gratulation. Langsam wird das Raytracing ja interessant und die Szenen sind nicht mehr ganz so langweilig. Es bleibt aber immer noch genügend Stoff für ein weiteres Grundlagen Tutorial: In Planung sind hier ein paar Worte bezüglich Reflexionen, Schatten und ein paar weiteren Objekten wie Dreiecken (das impliziert eine Lehrstunde in Sachen Phong Shading), Boxen und Zylinder. Dazu sollten wir ausserdem unseren Raytracer umbauen: Er wird in eine eigene Tracer-Klasse ausgelagert werden, um so schnell die Wahl zwischen verschiedenen Raytracern zu haben. Stay tuned.<br /> <br /> '''Delphic'''</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Raytracing_-_Grundlagen_I&diff=23933 2009-07-23T15:12:00Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>= Tutorial Raytracing - Grundlagen I =<br /> [[Bild:Tutorial_RaytracingI_teaser.jpg|center]]<br /> == Einführung ==<br /> Da melde ich mich mal wieder zurück mit einem kleinen Tutorial bezüglich Raytracing. Ihr sollt ja gelegentlich was neues lernen. Es ist zwar etwas schade, daß nur noch selten Tutorials aus der Community kommen - ich hoffe immernoch, daß sich das irgendwann wieder ändern wird. Und alle die bislang Tutorials geschrieben haben, mussten ja irgendwann ihr erstes schreiben - also nur Mut (mein allererstes war im Übrigen das 1. Tutorial aus der Terrain-Reihe). Nunja. Was hat es also mit dem Raytracing auf sich? Und warum heisst dieses Tutorial Grundlagen I? Ich will es euch erklären. Beim Raytracing verfolgt man im Gegensatz zum Rastern wie es etwa OpenGl oder Direct3D machen, einen anderen Ansatz. Statt Objekte oberflächlich in Polygone zu zerschneiden und sie dann auf den Bildschirm per Z-Buffer zu projezieren, wirft die Kamera Strahlen in die Szenerie und auf jedem Strahl prüft man, ob sich ein Objekt mit dem Strahl schneidet. Man verliert dadurch sehr deutlich Geschwindigkeit: die wenigsten Raytracer sind so schnell, dass man interaktiv damit arbeiten kann. Wozu also ist dann Raytracing gut? Man kann im Raytracer hoch realistisch wirkende Bilder erzeugen und auch Verfahren verwenden, die im Rasterizer nicht oder kaum nachzubauen sind - die gute alte Grafikkarte muss dabei nicht völlig unnütz werden: Diese besitzen sehr flotte und massiv parallele Geometrie-Einheiten, die auch im Raytracer Verwendung finden können - dies ist aber etwas zu speziell für unser kleines Tutorial und vielleicht auch nicht das, was man in seinem ersten Raytracer implementieren würde. Was sich im Bereich interaktiver Grafik allerdings anbietet, ist den Raytracer ein wenig umzumodeln und mit ihm statische Lightmaps erzeugen oder ihn zur Selection missbrauchen. Das einzige Problem welches wir dabei haben: Wir müssen alles von Grund auf zusammenbasteln - nicht so schön, wie bei OpenGl, wo man nach ein paar Stunden recht ansehnliche Bilder samt Beleuchtung zeichnen kann. Wir werden da wohl etwas länger brauchen, aber ewig wird es auch nicht dauern - und schliesslich musste OpenGl ja auch erst einmal designed werden. Andere Dinge werden sich dagegen deutlich leichter implementieren lassen als mit OpenGl, so sind etwa Schatten im Raytracer ein Kinderspiel - im Rasterizer können sie richtig arbeitsintensiv werden.<br /> <br /> == Die griechische Vorstellung ==<br /> [[Bild:Tutorial_RaytracingI_griechisch.jpg|right]]<br /> Die Griechen hatten eine etwas sonderbare Vorstellung vom Sehen: Sie stellten sich vor, dass aus ihren Augen Strahlen kommen, die dann auf die Umgebung treffen und quasi Nachricht an das Auge geben, was sie getroffen haben, wie weit weg es ist und welche Farbe es hat. Das ist in etwa das was auch ein Raytracer macht. Wir wollen das erst einmal im Hinterkopf behalten und uns zunächst mit Strahlen genauer auseinandersetzen. Danach werden wir Kugeln mit diesen Strahlen schneiden und eine passende perspektivische Kamera entwerfen. Schließlich werden wir einen sehr einfachen Raytracer schreiben, und ihm anschließend noch Ebenen als Objekte näherbringen, weil Kugeln alleine doch etwas langweilig sind.<br /> <br /> == Strahlen ==<br /> Was ist also ein Strahl? Ein Strahl hat einen Ursprung, an dem er beginnt, und eine Richung, in die er verläuft. Wer in der Schule in Geometrie aufgepasst hat, kennt dieses Objekt sicher auch noch als Halbgerade. Da wir später damit rechnen werden, müssen wir den Strahl in eine schöne Formel packen:<br /> [[Bild:Tutorial_RaytracingI_strahlgleichung.png|center]]<br /> Die Punkte auf unserem Strahl r sind also parametrisiert durch t, welches die<br /> Zahlen von 0 bis unendlich durchläuft. Der Ursprung des Strahles ist o und seine<br /> Richung d. Somit kennen wir alle Punkte auf dem Strahl. <br /> <br /> Um nun zu prüfen, ob ein Strahl nun ein Objekt trifft, beginnen wir bei t = 0 und laufen alle Punkte ab, bis wir bei t = unendlich angekommen ... ... ... Nein so machen wir das natürlich nicht - funktionieren würde es zwar, würde aber unendlich lange dauern: Nicht gerade das, was wir uns unter schnell vorstellen. <br /> <br /> Bevor wir weitermachen, sollten wir unseren Strahl gleich in<br /> etwas Code verpacken, schließlich wollen wir uns ja einen Raytracer schreiben:<br /> &lt;source lang=&quot;cpp&quot;&gt;public struct Ray<br /> {<br /> public Vertex3 Origin;<br /> public Vertex3 Direction;<br /> <br /> public Vertex3 Evaluate (double t)<br /> {<br /> return Origin + t * Direction;<br /> }<br /> }&lt;/source&gt;<br /> <br /> Zurück zu unserem Problem: Wir müssten also unendlich lange darauf warten, bis unser Raytracer das Objekt gefunden hat, mit dem sich der momentan betrachtete Strahl schneidet. Viel schneller geht die Sache, wenn wir vorher beschließen, welche Objekte wir anzeigen können wollen. Für den Anfang wollen wir uns mit sehr einfachen Objekten begnügen: Kugeln. Sie sind schnell berechnet und werden für erste Experimente ausreichen.<br /> <br /> == Kugeln ==<br /> Erinnerung: Eine Kugel ist definiert durch ihren Mittelpunkt und ihren Radius r. Setzt man den Mittelpunkt auf den Ursprung des Koordinatensystems, dann sind die Punkte auf der Oberfläche O unserer Kugel gerade die Punkte, die vom Ursprung den Abstand r haben. Die uns interessierende Bedingung wird so zu ||p|| = r für Punkte p auf O. Die Gleichung kann man schadlos quadrieren und statt der Vektorlänge ||p|| bekommt man das ohne Wurzel ziehen zu berechnende [[Standard Skalarprodukt|Skalarprodukt]] von p mit sich selbst:<br /> [[Bild:Tutorial_RaytracingI_skalprodpp.png|center]]<br /> Setzt man hierein die obige Gleichung für den Strahl, ergibt sich:<br /> [[Bild:Tutorial_RaytracingI_radsqr.png|center]]<br /> Und damit:<br /> [[Bild:Tutorial_RaytracingI_radsqr2.png|center]]<br /> Da die Richtung o und d unseres Strahls bekannt sind, haben wir eine quadratische Gleichung vor der Nase, die wir mittels Mitternachtsformel lösen können:<br /> [[Bild:Tutorial_RaytracingI_mitternacht.png|center]]<br /> Anhand der Diskriminante D, also dem Teil des obigen Ausdrucks, der unter der Wurzel steht, können wir entscheiden, ob der Strahl die Kugel trift. Ist nämlich D &lt; 0, so kann man in den reelen Zahlen die Wurzel nicht berechnen. Ist D = 0, so gibt es genau eine Lösung der Schnittgleichung und für D &gt; 0 schneidet der Strahl die Kugel genau 2 mal. Da wir unseren Strahl nur für positive Parameter t definiert haben, sollten wir die errechneten Schnittpunkte t&lt;sub&gt;1&lt;/sub&gt; und t&lt;sub&gt;2&lt;/sub&gt; noch daraufhin untersuchen:<br /> &lt;source lang=&quot;cpp&quot;&gt;public double RayIntersect ( Ray ray )<br /> {<br /> double boundingSquare = sphereRadius * sphereRadius ;<br /> ray.Origin -= Position;<br /> double a, b, c;<br /> a = ray.Direction.DotDot ;<br /> // DotDot ^= Skalarprod mit sichselbst : &lt;d, d&gt;<br /> b = 2 * ( ray.Origin * ray.Direction );<br /> // * ^= normales Skalarprod<br /> c = ray.Origin.DotDot - boundingSquare;<br /> <br /> double t1 , t2 ;<br /> int roots = CalcQuadricRoots (a, b, c, out t1, out t2) ;<br /> <br /> if (roots &gt; 0)<br /> return t1 &gt;= 0 ? t1 : t2 ;<br /> // kleinsterpositiver pos. Wert aus t1, t2<br /> else<br /> return -1; // Kein Schnittpunkt<br /> }&lt;/source&gt;<br /> Einen kleinen Haken hat die Sache jedoch: Analytisch, d.h. per Stift und Papier, lässt sich mit der Mitternachtsformel wunderbar rechnen. Am Computer neigt sie zu Fehlern, was ganz allein an dem &amp;plusmn; liegt. So führt man verlässlich eine Subtraktion durch, wenn D &gt; 0 ist - und Subtraktionen sind reines Gift für die Genauigkeit bei numerischen Rechnungen. Durch kleine Umformungen und das Bestimmen eines Vorzeichens, können wir das Problem umgehen:<br /> <br /> == Quadratische Gleichungen ==<br /> Hat man also eine Quadratische Gleichung in der allgemeinen Form:<br /> [[Bild:Tutorial_RaytracingI_quadratisch.png|center]]<br /> dann bestimmt man die Nullstellen am besten durch:<br /> [[Bild:Tutorial_RaytracingI_quadratisch_numerisch.png|center]]<br /> Bei der Auswertung von q wird so sicherlich echt addiert, weil zu b eine Zahl gleichen Vorzeichens summiert wird. Dass der Wert für t&lt;sub&gt;1&lt;/sub&gt; stimmt, hat man dann auch sehr leicht nachgerechnet, wohingegen t&lt;sub&gt;2&lt;/sub&gt; in wildes Rumgeschiebe der Formel ausartet und sich erst recht spät sign(b) herauswerfen lässt. Ich erspare euch nähere Erläuterungen ;-) Ein bischen Quellcode hierzu:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;public static int CalcQuadricRoots(double a, double b, double c, out double x1, out double x2)<br /> {<br /> double determinant = b * b - 4 * a * c;<br /> if (determinant &lt; 0)<br /> {<br /> x1 = 0.0;<br /> x2 = 0.0;<br /> return 0;<br /> }<br /> determinant = Math.Sqrt(determinant);<br /> double q = -0.5 * (b + PSgn(b) * determinant);<br /> // Psgn: gives - 1 if b &lt; 0 and 1 if b &gt;= 0. <br /> // so no zero as normal sgn would give us.<br /> x1 = q / a;<br /> x2 = c / q;<br /> // Sort by value<br /> if (x1 &gt; x2)<br /> {<br /> q = x2; x2 = x1; x1 = q;<br /> }<br /> return x1 == x2 ? 1 : 2;<br /> }&lt;/source&gt;<br /> Die Funktion speichert die Nullstellen in den Variablen x1, x2 dem Wert nach sortiert ab und gibt die Anzahl der Nullstellen zurück.<br /> Da wir jetzt bereits bestimmen können, wo und wie oft unser Strahl die Kugel trift, können wir, nachdem wir uns noch einen Strahlenwerfer, (also eine Kamera) konstruiert haben, unseren ersten Raytracer bauen.<br /> <br /> == Perspektivische Kamera ==<br /> Jeder, der sich mit OpenGL auskennt, wird bei der Konstruktion einer perspektivischen Kamera gleich schreien, daß man dazu doch einfach nur eine Projektionsmatrix braucht, die man sich ganz einfach aus der OpenGL Spezifikation stibitzen kann. Falsch gedacht: Ein Raytracer ist kein Rasterizer: Wir brauchen keine Projektionsmatrizen, noch nicht einmal Matrizen. Die perspektivische Kamera eines Ray-Tracers lässt sich direkt nach vorn heraus entwerfen:<br /> <br /> [[Bild:Tutorial_RaytracingI_perspektivisch.png|center]]<br /> <br /> Unrotiert und unverschoben soll unsere Kamera in die Tiefenrichtung z blicken. Dabei wird unser Bildschirm durch die Parameter links, rechts, oben und unten beschrieben. Ist die Auflösung des Bildschirms in X wie in Y-Richtung bekannt, so kann man leicht die Richtung d des Vektors bestimmen, der vom Betrachter auf den Bildschirm zeigt. Sofort bekommt man so einen Strahl, wenn man als Anfangspunkt o die Position des Betrachters wählt:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;public Ray ShootRay ( int x , int y )<br /> {<br /> Ray result = new Ray();<br /> result.Origin = Position;<br /> <br /> double xpart , ypart ;<br /> xpart = ( ( double ) x ) / (double ) widthpixels;<br /> ypart = ( ( double ) y ) / (double ) heightpixels;<br /> <br /> xpart = left + xpart * ( right - left ) ;<br /> ypart = top + ypart * ( bottom - top ) ;<br /> <br /> result.Direction.x = xpart;<br /> result.Direction.y = ypart;<br /> result.Direction.z = 1.0;<br /> <br /> /* if ( Transformation != null )<br /> {<br /> result.Direction =<br /> Transformation.Apply( result.Direction );<br /> } */<br /> result.Direction.Normalize();<br /> return result;<br /> }&lt;/source&gt;<br /> Die auskommentierte if-Abfrage soll vorerst nicht stören. Ihr wird später leben eingehaucht, wenn wir dem Raytracer Verschiebungen,<br /> Rotationen, Skalierungen, Scheerungen, u.s.w. einbauen.<br /> <br /> == Einfacher Raycaster ==<br /> [[Bild:Tutorial_RaytracingI_depthcasting.jpg|right]]<br /> Damit sind wir dann auch schon soweit, daß wir unsere ersten Gehversuche in Sachen Raytracing wagen können. Für jedes Pixel im Bild werfen wir mittels ShootRay einen Strahl und prüfen, ob dieser die Kugeln in unserer Szene schneidet. Wenn ja, merken wir uns den nähestes dieser Schnittpunkte und weisen ihm einen Farbwert zu. So erhalten wir ein Bild, das in etwa die Informationen wieder gibt, die OpenGl in seinem Tiefenpuffer speichern würde. Ich gebe zu, das ist nicht hochgradig spannend, aber solange wir uns noch nicht eingehender mit Licht und Shading beschäftigt haben, können wir auch nicht mehr erwarten - und wir haben beim Raytracing ja leider das Problem, daß wir ganz von vorne anfangen müssen:<br /> <br /> &lt;source lang=&quot;cpp&quot;&gt;public RaytraceImage ( int width , int height )<br /> {<br /> // near und far sind die Werte fuer den Bereich ,<br /> // von dem Tiefeninformationen abgebildet werden<br /> for ( int x = 0; x &lt; width; x++) {<br /> for ( int y = 0 ; y &lt; height; y++) {<br /> Ray shoot = ShootRay (x , y);<br /> double maxdist = double.Infinity;<br /> <br /> foreach (Kugel obj in SichtbareKugeln) {<br /> double hitdist = obj.RayIntersect(shoot) ;<br /> if (hitdist &gt; 0 &amp;&amp; maxdist &gt; hitdist)<br /> maxdist = hitdist;<br /> }<br /> <br /> if (maxdist &lt; double.Infinity) {<br /> SetColor(x, y, Colors.Gray (Math.Min(Math .Max(0,<br /> (maxdist - near) / ( near - far ))), 1.0)) ;<br /> }<br /> else<br /> SetColor(x, y, BackgroundColor); <br /> }<br /> }<br /> }&lt;/source&gt;<br /> Eine kleine Anmerkung noch: Da wir uns noch nicht über Transformationen Gedanken gemacht haben, und unsere Kugeln bislang am Nullpunkt aufgehäng sind, können wir diese noch nicht positionieren - sprich es wird höchstens die größte Kugel sichtbar, weil alle weiteren verdeckt sind. Das lässt sich beheben, indem man vor dem Test auf Schnitt vom Ursprung des entsprechenden Strahles, die Position der Kugel abzieht.<br /> <br /> == Ebenen ==<br /> Mit Kugeln kann man zwar so einiges darstellen, aber nur Kugeln sind vielleicht doch etwas langweilig. Wir wollen deshalb noch Ebenen implementieren. Am besten betrachten wir diese dazu in der Normalform, d.h. die Ebene wird allein durch ihre Flächennormale angegeben. Für Punkte auf der Ebene gilt dann:<br /> [[Bild:Tutorial_RaytracingI_ebenengleichung.png|center]]<br /> Setzt man nun in x unseren Strahl ein, ergibt sich:<br /> [[Bild:Tutorial_RaytracingI_ebenenrechnung.png|center]]<br /> Ist &lt;d,n&gt;=0, dann gibt es keine Lösung, sonst genau eine. <br /> <br /> Welche Objekte eignen sich sonst gut zum Raytracing? ... Alle Objekte, die sich in kartesischen Koordinaten durch eine Gleichung der Form [[Bild:Tutorial_RaytracingI_kartesisch.png|center]] darstellen lassen. In (x,y,z) setzt man seinen Strahl r(t) ein und versucht nach t aufzulösen. In einigen Fällen wird dieses Problem leider kaum zu lösen sein: man kommt dann um den Einsatz von numerischen Verfahren nicht herum. Ich werde versuchen, in Folgetutorials noch ein paar weitere, interessante Objekte vorzustellen, die sich direkt lösen lassen und wenn ich viel Geduld habe, vielleicht auch einmal einen eigenen Artikel bezüglich numerischer Verfahren.<br /> <br /> == Vorschau ==<br /> Damit sind wir auch schon wieder soweit. Die ersten Grundlagen sind abgehandelt, aber wirklich überzeugt sind wir vom Raytracing noch nicht. Damit sich das ändert, sind weitere Tutorials in Planung: Wir wollen uns dann mit Licht und Normalen beschäftigen. Ausserdem sind Reflektionen und Transparenz spannende Dinge, denen wir uns widmen können. Wir wollen ausserdem unsere Objekte transformieren, scheeren, rotieren, ... Es bleibt also noch einiges im Bereich Raytracing zu tun, was hier nicht behandelt wurde.<br /> <br /> Bis es soweit ist, könnt ihr euch ja selbst schonmal ein paar Gedanken zum Thema machen oder euch doch lieber in die Weiten von OpenGl flüchten.<br /> <br /> '''Delphic'''</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Terrain3&diff=23931 2009-07-23T15:11:35Z

<p>Delphic: -&gt;delphic</p> <hr /> <div>=Continuous Level of Detail fur Heightmaps=<br /> <br /> ==Einführung==<br /> <br /> Hi, <br /> <br /> Ich habe in meinem ersten Heightmap Tutorial im Nachwort erzahlt, dass ich vielleicht ein Tutorial uber Level of Detail (LOD) fur Heightmaps schreibe. Ich will hiermit mein Versprechen einlosen, will euch aber auch gleich warnen, es ist nicht so leicht, wie man eigentlich denken konnte, denn viele Probleme stellen sich einem in den Weg, z.B. Cracks im [[Mesh]]. <br /> <br /> Erkundigt man sich unter Spieleentwicklern nach LOD fur Heightmaps, wird man in den meisten Fallen wohl auf den Begriff ROAMing stosen. Dieser wird z.B. in einem meiner Lieblingsgames Tribes 2 verwendet. Mich hat dieser Algorithmus nicht wirklich angesprochen und ich habe weitergesucht. Nach einiger Zeit bin ich auf den Algorithmus aufmerksam geworden, der im Spiel Aquanox sein Konnen zeigt. Genauer gesagt bin ich uber das [http://www.vterrain.org Virtual Terrain Project] darauf gestosen. Das Original Script von [http://www9.cs.fau.de/Persons/Roettger Stefan Rottger] findet sich direkt auf seiner Homepage unter Terrain Rendering: [http://wwwvis.informatik.uni-stuttgart.de/~roettger/data/Papers/TERRAIN.PDF Real-Time Generation of Continuous Levels of Detail for Height Fields] Ich kann euch wirklich warmstens empfehlen, dieses Script sich einmal genauer anzuschauen - sehr interessant. In diesem Tutorial werde ich das Schriftstuck etwas genauer beleuchten und ein paar Hilfestellungen dazu geben, in der Hoffnung, dass ihr es mir gleich tut und diesen Algorithmus selbst einmal nachbaut.<br /> <br /> ==Quadtree==<br /> <br /> Der Ganze Algorithmus basiert auf einem Quadtree. Dieser wird durch eine Boolean Matrix(fur die Delpher, die immer noch nicht wissen, was eine Matrix ist: Wir reden uber ein 2 Dimensionales '''Array[0..n,0..n] of Boolean''') reprasentiert, so kann man sich eine Menge Pointer(und damit Speicherplatz) und viel Rechenarbeit sparen. Wir gehen davon aus, dass die Matrix eine Grose von (2n+1)x(2n+1) hat. Idealerweise hat die verwendete Heightmap die gleichen Ausmase. Die Hauptnode sitzt in der Mitte der Matrix, die 4 Kinder... Bevor ich in Erklarungsnote komme, hier einfach ein Bild, das den Sachverhalt verdeutlichen soll:<br /> <br /> [[Bild:Tutorial_Terrain3_quadmatrix.gif|center]]<br /> <br /> Ok, wir wissen nun, wie die Matrix aufgebaut ist, wie die Mutter Kind Verhaltnisse des Quadtrees sind, etc., nur ist noch immer nicht klar, wozu diese Matrix. Wie bereits gesagt, handelt es sich um eine Boolean Matrix. Die Werte, die die Matrix annehmen kann, sind True oder False :-). Diese sagen aus, ob eine Node gesetzt ist und damit gezeichnet wird, oder eben nicht. Unsere Ziele sind also zum einen die Matrix rendern und zum andern die Matrix berechnen<br /> <br /> ==Rendern der Heightmap==<br /> <br /> Unsere Landschaft wird gerendert, indem wir den Quadtree rekursiv entlanggehen und immer wenn ein Endpunkt des Baums erreicht wird, wird ein kompletter oder teile eines Dreieck Fans gezeichnet. Diese Fans sind besonders gut dazu geeignet, ohne Locher und Cracks im Mesh ein Heighfield darzustellen:<br /> <br /> [[Bild:Tutorial_Terrain3_setmatrix.gif]]<br /> [[Bild:Tutorial_Terrain3_triangulation.gif]] <br /> <br /> Das linke Bild stellt eine Beispiel Matrix dar, das rechte die dazu passende Triangulation. Ihr konnt gerne nach Stellen suchen, an denen die Moglichkeit besteht, dass dort ein Crack ist. Ihr werdet keine finden. Zuerst wird einmal davon ausgegangen, dass der Levelunterschied im Quadtree zweier benachbarter Blocke niemals mehr als 1 betragt. Diese Bedingung wird beim Berechnen der Matrix abgesichert, dazu spater mehr. Das Zentrum eines Fans, ist immer auch das Zentrum eines Quadtree Blattes. Vier Vertieces bilden die Ecken des Blocks und weitere 4 bilden jeweils die Mittelpunkte der Seiten des Blattes:<br /> <br /> [[Bild:Tutorial_Terrain3_fan.gif]]<br /> <br /> Es werden also hochstens 8 Dreiecke gezeichnet. Hat eine Seite keinen benachbarten Block gleichen Levels, so wird das Vertex in der Mitte der Seite einfach ubersprungen, was zur obigen Beispiel Triangulation fuhrt.<br /> <br /> <br /> ==Erzeugen der Matrix==<br /> <br /> LOD besagt, dass Gegenstande in groser Entfernung mit einer niedrigeren Auflosung angezeigt werden, als nahe Objekte. Daneben werden auch bei groserer Entfernung bestimmte Teile eines Meshes mit hoherer Auflosung angezeigt, deren Oberflache besonders uneben ist, wodurch die Bildqualitat stark erhoht wird.<br /> <br /> <br /> ===Oberflachenfehler===<br /> <br /> Fehler? Fehler?!? Will ich euch jetzt verarschen, ware doch dumm Fehler zu machen... Nein, die gemeinten Fehler besagen ausschlieslich, wie verfalscht eine Stelle in der Landschaft aussehen wurde, wenn man beim Hinuntergehen des Baumes an der aktuellen Stelle aufhort und zu rendern beginnt. Je hoher dieser Wert, desto wichtiger ist es, den Baum noch tiefer hinabzuschreiten.<br /> <br /> [[Bild:Tutorial_Terrain3_dhvalues.jpg|center]]<br /> Um diese '''d2''' genannten Werte fur ein Quadree Blatt zu erhalten, errechnet man zuerst die Erhebungsunterschiede an den Mitten der 4 Seiten und an den 2 Diagonalen(Achtung: das sind unterschiedliche Werte). Der '''d2''' Wert errechnet sich daraus so:<br /> <br /> '''d2=(1/d)*maxi=1..6|dhi|'''<br /> <br /> In Delphi konnte das ganze dann so aussehen:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure CalcD2Value(X, Z, Size : Longint);<br /> var<br /> HSize : LongInt; //Hälfte der eigenen Seitenlänge<br /> I : LongInt;<br /> EdgeHeights : Array[1..4] of Single; //Höhe der Ecken<br /> ExpectedHeight : Single; //Erwartete höhe zw 2 Punkten<br /> RealHeight : Single; //Tatsächliche Höhe<br /> <br /> DHValues : Array[1..6] of Single; //DHWerte<br /> <br /> const<br /> //Ort der Ecken des Quads<br /> Edges : Array[1..4] of Array[0..1] of ShortInt = ((+1, +1),(+1, -1),(-1,-1),(-1,+1));<br /> //Jeweils die 2 Ecken, zwischen denen ein DHWert berechnet wird<br /> DHLines : Array[1..6] of Array[0..1] of Byte =<br /> ((1,2),(2,3),(3,4),(4,1),(1,3),(2,4));<br /> <br /> //Positionen der DHWerte selber<br /> DHPositions : Array[1..6] of Array[0..1] of ShortInt =<br /> ((1,0),(0,-1),(-1,0),(0,1),(0,0),(0,0));<br /> <br /> begin<br /> //Höhen der 4 Ecken<br /> for I := 1 to 4 do<br /> EdgeHeights[I] := GetHeightMapHeight(X + Size * Edges[i,0],<br /> Z + Size * Edges[i,1]);<br /> <br /> //DHWerte berechen<br /> for i := 1 to 6 do<br /> begin<br /> //Erwartete Höhe zwischen 2 Punkten<br /> ExpectedHeight := (EdgeHeights[DHLines[i,0]] + EdgeHeights[DHLines[i,1]])/2;<br /> //Tatsächlich vorliegende Höhe<br /> RealHeight := GetHeightMapHeight(<br /> X + DHPositions[i,0] * Size,<br /> Z + DHPositions[i,1] * Size);<br /> //DH Wert ist |absoluter Fehler|<br /> DHValues[I] := Abs(ExpectedHeight - RealHeight)<br /> end;<br /> <br /> //D2Value finden und setzen<br /> QuadMatrix[X,Z].D2Value := Trunc(1/(2*Size) * Max(DHValues));<br /> <br /> //D2Values für die 4 Kinder<br /> if Size &gt; 1 then<br /> begin<br /> HSize := Size div 2;<br /> CalcD2Value(X + HSize, Z + HSize, HSize);<br /> CalcD2Value(X + HSize, Z - HSize, HSize);<br /> CalcD2Value(X - HSize, Z + HSize, HSize);<br /> CalcD2Value(X - HSize, Z - HSize, HSize)<br /> end<br /> end; (*CalcD2Values*)<br /> ...<br /> CalcD2Value((QuadTreeLength-1) div 2, (QuadTreeLength-1) div 2,<br /> (QuadTreeLength-1) div 2);<br /> ...<br /> &lt;/source&gt;<br /> <br /> In diesem Beispiel steht '''Size''' immer fur die Halfte der Seitenlange einer Quadtreenode. Man denke hier am Besten an den Radius eines Kreises. Die '''d2''' Werte werden auf Bytegrose komprimiert, um wertvollen Speicher einzusparen.<br /> <br /> <br /> ===Matrix erzeugen===<br /> <br /> Jetzt wollen wir uns daran machen, die furs Zeichnen unbedingt notige Matrix zu erzeugen. Gehen wir einmal davon aus, dass die Matrix bereits sauber entleert ist und damit kein Node als gesetzt gilt. Wir laufen den Quadtree wieder rekursiv hinab und entscheiden an jeder Node nach folgender Formel, ob weiter unterteilt werden muss oder nicht:<br /> <br /> '''f=l/(d*C*max(c*d2, 1)'''<br /> <br /> Ist der Wert von '''f''' kleiner 1, dann wird weiter unterteilt. Es gilt: '''C''' ist eine feste Konstante. Je hoher sie ist, desto hoher ist die Landschaft insgesamt aufgelost. '''l''' ist die Entfernung des Node Mittelpunkts zur Kamera und klein '''c''' kontrolliert die Auflosung in Bereichen, die einen hohen Oberflachenfehler aufweisen.<br /> <br /> <br /> ===Schweizer Kase===<br /> [[Bild:Tutorial_Terrain3_kaese.jpg|center]]<br /> Das bisherige Ergebnis ist doch mehr ernuchternd als erfreulich. Es sieht alles mehr nach Schweizer Kase aus. Viele Locher, aber sonst nicht viel zu bieten. In einem Spiel kann man so ganz schnell dem Spieler den Spass verderben, wir sollten also etwas dagegen unternehmen.<br /> <br /> Um dieses Ziel zu erreichen, mussen wir ganz einfach die '''d2''' Werte so verandern, dass Nebeneinanderliegende Blocke keinen Levelunterschied groser als 1 aufweisen (Bedingung für das Rendern der Matrix, siehe oben). Zuerst mussen also die '''d2''' Werte einmal berechnet worden sein. Nun gehen wir den Quadtree wieder soweit herunter, bis wir genau 1 level vor dem niedrigsten sind und setzen den '''d2''' Wert der Node neu:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> QuadMatrix[X,Z].D2Value := Max(QuadMatrix[X,Z].D2Value, <br /> (d2Werte der benachbarten Nodes ein Level tiefer) * K)<br /> K = C / (2 * (C - 1)); C groser 2<br /> &lt;/source&gt;<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure DoCrackAvoid(X, Z, Size, SizeToCheck : Longint);<br /> const<br /> Neighbours : Array[0..8] of Array[0..1] of ShortInt =<br /> ((+0,+0), (+3,+1),(+3,-1),(+1,-3),(-1,-3),(-3,-1),(-3,+1),(-1,+3),(+1,+3));<br /> var<br /> HSize : LongInt; //1/4 der Seitenlänge<br /> I : LongInt;<br /> D2Values : Array[0..8] of Byte;<br /> <br /> begin<br /> Assert(Size &gt; 1);<br /> //Der Baum wird rekursiv abgehandlet(nicht unbedingt die<br /> //beste Idee. Wer Lust hat, darf sich gerne daran versuchen<br /> //es einmal ohne Rekursivität zu probieren!)<br /> <br /> HSize := Size div 2;<br /> //Wir haben noch nicht das gewünschte Level erreicht<br /> if Size &gt; SizeToCheck then<br /> begin<br /> DoCrackAvoid(X + HSize, Z + HSize, HSize,SizeToCheck);<br /> DoCrackAvoid(X + HSize, Z - HSize, HSize,SizeToCheck);<br /> DoCrackAvoid(X - HSize, Z + HSize, HSize,SizeToCheck);<br /> DoCrackAvoid(X - HSize, Z - HSize, HSize,SizeToCheck)<br /> end<br /> else<br /> begin<br /> Assert(SizeToCheck = Size);<br /> D2Values[0] := QuadMatrix[X,Z].D2Value;<br /> for i := 1 to 8 do<br /> //Nachbarnodes holen....<br /> D2Values[i] := GetNode(X + HSize * Neighbours[i][0],<br /> Z + HSize * Neighbours[i][1]) * K;<br /> <br /> QuadMatrix[X,Z].D2Value := MaxByte(D2Values)<br /> end<br /> end; (*DoCrackAvoid*)<br /> &lt;/source&gt;<br /> <br /> Diesen Vorgang wiederholen wir, wobei wir immer ein Level niedriger gehen, bis wir schlieslich das Level 1 erreichen. Wenn wir nun unsere Matrix berechnen, ist unsere Bedingung erfullt und wir erhalten ein Mesh ohne Locher:<br /> <br /> [[Bild:Tutorial_Terrain3_result.jpg|center]]<br /> <br /> [[Bild:Tutorial_Terrain3_wireframe.jpg|center]]<br /> <br /> Wer glaubt hier ein paar Locher finden zu konnen liegt falsch. Die Stellen die schwarz erscheinen, werden durch das OpenGl Licht nur so unglucklich getroffen, dass sie fast schwarz erscheinen. Ist euer Monitor richtig eingestellt, sollte dagegen alles passen. Siehe dazu auch: [[Farbraum]]{{excIcon}}. Die &quot;Kamera&quot; befindet sich übrigens links unten im Bild, dort wo ein rotes Quad sichtbar ist.<br /> <br /> '''Anmerkung:''' Nach Aussage von Stefan Röttger ist diese Methode um Löcher zu entfernen nicht optimal. Es genügt bei jedem Vater Knoten alle Kinder in die Berechnung einzubeziehen. Die Nachbarn müssen nicht einbezogen werden. Genaueres findet sich in diesem [http://www.delphigl.com/forum/viewtopic.php?p=48761#48761 Forumsbeitrag].<br /> <br /> ==Nachwort==<br /> <br /> Wie gehts weiter?<br /> Um die ganze Sache nun noch ein bischen weiter zu verbessern, sollte man uberlegen, ob man die Landschaft nicht vielleicht texturiert. Hier bietet sich sicher das [[Tutorial_Terrain2|2. Highmap Tutorial]] als guter Anfang an. Auch konnte man das &quot;Popping&quot; unterbinden, das auftritt, wenn man sich einer Stelle nahert und plotzlich ein paar neue Dreiecke angezeigt werden. Das ganze ist bekannt unter dem Begriff Geomorphing. <br /> <br /> Delphic<br /> <br /> == Dateien ==<br /> * {{ArchivLink|file=tut_terrainclod_delphi_vcl|text=Delphi-VCL-Quelltext zum Tutorial}}<br /> * {{ArchivLink|file=tut_terrainclod_exe|text=Windows-Binary zum Tutorial}}<br /> <br /> {{TUTORIAL_NAVIGATION|[[Tutorial_Terrain2]]|[[Tutorial_Skyboxen]]}}<br /> <br /> [[Kategorie:Tutorial|Tutorial3]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Terrain2&diff=23930 2009-07-23T15:10:52Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>=Heightmap Texturen=<br /> <br /> ==Vorwort==<br /> <br /> Hi, <br /> <br /> dies ist ein weiteres Tutorial zu Heightmaps. Ich verrate euch heute, wie man Heightmaps ein paar interessante Texturen verpasst. Der erste Teil besteht darin, eine Procedural Texture zu erstellen, die eine Kombination aus der Heightmap und einer Wahl von Bodentexturen ist, z.B. werden die höchsten Punkte der Landschaft mit Schnee bedeckt sein, niedrigere mit Stein, Gras und zum Schluss Wasser. <br /> <br /> Der zweite Teil besteht darin, eine Lightmap zu Rendern. Sie enthält die Lichtintensitat der einfallenden Sonne auf der Karte. <br /> Damit ihr wisst, wofür die ganze Müh erst einmal ein kleiner Teaser: <br /> <br /> [[Bild:Tutorial_Terrain2_result.jpg|center|framed|Besonders zu beachten: Die Landschaft wirft Schatten auf sich selbst]]<br /> <br /> ==Der Trick der Procedural Textures==<br /> <br /> Wollen wir uns zuerst den Procedural Textures widmen. Die Idee: <br /> <br /> Wir haben eine Heightmap. Wir wollen über diese eine Textur ziehen. Je nach Hohe soll eine andere Grundtextur gewählt werden, z.B. Hohenstufe 0 Unterwassertextur. Stufe 60 Sand, Stufe 100 Gras, 170 Stein und 255 Schnee. Daneben wollen wir erreichen, dass die Texturen ineinander übergehe, indem wir immer genau zwischen zwei Stufen die Farbwerte linear interpolieren. Die Grundtexturen werden gekachelt, damit sie nicht so hoch aufgelöst werden müssen, wie die Heightmap selbst.<br /> <br /> Ich habe folgende Texturen verwandt:<br /> &lt;div align=&quot;center&quot;&gt;<br /> {| {{Prettytable_B1}}<br /> |[[Bild:Tutorial_Terrain2_underwater.jpg]]<br /> |[[Bild:Tutorial_Terrain2_sand.jpg]]<br /> |[[Bild:Tutorial_Terrain2_grass.jpg]]<br /> |[[Bild:Tutorial_Terrain2_rock.jpg]]<br /> |[[Bild:Tutorial_Terrain2_snow.jpg]]<br /> |-<br /> |Stufe: 0 <br /> |Stufe: 60 <br /> |Stufe: 100 <br /> |Stufe: 170 <br /> |Stufe: 255 <br /> |}&lt;/div&gt;<br /> <br /> {{Hinweis|Wenn ihr selbst Texturen erstellen wollt, zeichnet oder fotografiert wild drauf los, und lasst einen Kachel Filter in einem Bildbearbeitungsprogramm drüberlaufen. Von Hand Kacheln erzeugen geht natürlich auch, bedarf aber deutlich mehr Aufwandt.<br /> <br /> Bevor wir unsere Textur rendern können, müssen wir uns eine Umgebung schaffen. Wir brauchen eine geladene Heightmap und die Grundtexturen: <br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> type<br /> TProcTexStage = record<br /> Image : TImage;<br /> ScrollBox : TScrollBox;<br /> Stage : Byte;<br /> StageLabel : TLabel;<br /> end;<br /> ...<br /> HeightMap : TBitMap;<br /> <br /> ProceduralTex : TBitMap;<br /> ProcTexs : Array of TProcTexStage;<br /> ...<br /> &lt;/source&gt;<br /> <br /> Der Typ '''TProcTexStage''' beinhaltet je eine Grundtextur, geladen in der '''Image''' Komponente. Die jeweilige Höhenstufe ist in '''Stage''' abgelegt. Die restlichen Objekte sind nur für die GUI gedacht und haben keine weitere Bedeutung für den Algorithmus selbst. <br /> <br /> Die Variable '''ProcTexs''' enhalt mehrere '''TProcTexStages'''. Sie sind bereits nach Stufen sortiert, beginnend mit der kleinsten, wobei gilt: Die niedrigste Stufe ist immer 0, die Hochste immer 255 (wird spater wichtig). Die Mindestzahl der Elemente ist demnach 2. Mehr ist kein Problem, unterschiedliche '''TProcTexStage''' sollten aber niemals die selbe Stufe haben. <br /> <br /> Sobal diese Annahmen erfüllt sind, können wir beginnen, jedem Pixel der '''ProceduralTex''' einen neuen Farbwert zuzuweisen. Das Grundgerüst ist wie folgt:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> ...<br /> var<br /> X,Y, HeightMapHeight : LongInt;<br /> ...<br /> begin<br /> //Texturen sind bereits sortiert...<br /> if Length(ProcTexs) &lt; 2 then<br /> Exit;<br /> //Größe anpassen<br /> ProceduralTex.Width := HeightMap.Width;<br /> ProceduralTex.Height := HeightMap.Height;<br /> <br /> for X := 0 to HeightMap.Width - 1 do<br /> for Y := 0 to HeightMap.Height - 1 do<br /> begin<br /> HeightMapHeight :=<br /> Trunc((HeightMap.Canvas.Pixels[X,Y]/clWhite)*255);<br /> //Farbwert zuweisen<br /> ...<br /> end<br /> end;<br /> &lt;/source&gt;<br /> <br /> Da wir die Stufen nicht auf bestimmte Werte festgelegt haben (z.B. alle 64 Hohenwerte eine Stufe) müssen wir zunächst das Intervall finden, in welchem die aktuelle Stufe liegt. Die jeweils niedrigere Textur wird in einer Variable '''Lower''' abgelegt, die höhere in '''Upper'''. Daneben benötigen wir noch einen Satz weiterer Variablen: <br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> var<br /> ...<br /> I : Integer;<br /> Upper, Lower : LongInt;<br /> LevelDifference : LongInt; //Levelunterschied zw. Upper u. Lower<br /> LowerDifference : LongInt; //Abstand HeightmapHeight - Lower<br /> LowerRGB, UpperRGB : TRGB; //RGB werte von Upper Lower<br /> Prozent : Single; //Prozent der eingesetzten Farbwerte<br /> FinalRGB : TRGB; //End RGB Wert<br /> <br /> ...<br /> HeightMapHeight := Trunc(<br /> (HeightMap.Canvas.Pixels[X,Y]/clWhite)*255);<br /> Upper := 0;<br /> Lower := 0;<br /> //Intervall suchen, das für diese Höhenstufe interessant ist<br /> // Schonmal was von binärer Suche gehört? <br /> for I := 1 to Length(ProcTexs)-1 do<br /> if HeightMapHeight &lt;= ProcTexs[I].Stage then<br /> begin<br /> Upper := I;<br /> Lower := I -1;<br /> Break<br /> end;<br /> Assert(Upper &lt;&gt; 0);<br /> LevelDifference := ProcTexs[Upper].Stage - ProcTexs[Lower].Stage;<br /> LowerDifference := HeightMapHeight - ProcTexs[Lower].Stage;<br /> Assert(LevelDifference &lt;&gt; 0);<br /> Prozent := LowerDifference / LevelDifference;<br /> ...<br /> &lt;/source&gt;<br /> <br /> Der verwendete Typ '''TRGB''' ist ein '''Array[0..2] of Byte'''. Wenn ein '''TColor''' Wert als Ausgangsmaterial dient, wird dieser mit in ein '''TRGB''' umgewandelt:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure MakeRGB(Color : TColor; var RGB : TRGB);<br /> begin<br /> Move(Color, RGB[0], 3)<br /> end;<br /> &lt;/source&gt;<br /> <br /> Damit haben wir's fast geschafft. Das einzige was noch fehlt ist die lineare Interpolation zwischen den Farbwerten der '''Upper''' und '''Lower''' Textur. Dies ist aber an sich nicht weiter schwierig. Man denke an den Mathematikunterricht zurück und erinnert sich an folgende gleichung: '''y= m * x + t''', wobei '''m''' die Steigung und '''t''' der y-Achsenabschnitt ist:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> ...<br /> Prozent := LowerDifference / LevelDifference;<br /> <br /> MakeRGB(ProcTexs[Lower].Image.Canvas.<br /> Pixels[X mod ProcTexs[Lower].Image.Width,<br /> Y mod ProcTexs[Lower].Image.Height],LowerRGB);<br /> MakeRGB(ProcTexs[Upper].Image.Canvas.<br /> Pixels[X mod ProcTexs[Upper].Image.Width,<br /> Y mod ProcTexs[Upper].Image.Height],UpperRGB);<br /> <br /> for I := 0 to 2 do<br /> FinalRGB[I] := Trunc(<br /> (UpperRGB[I] - LowerRGB[I])*Prozent +<br /> LowerRGB[I]);<br /> // y = ( m )* x + t<br /> ProceduralTex.Canvas.Pixels[X,Y] := RGB(FinalRGB[0],<br /> FinalRGB[1],<br /> FinalRGB[2])<br /> &lt;/source&gt;<br /> <br /> Zum Einsatz kam folgende Heightmap: <br /> <br /> [[Bild:Tutorial_Terrain2_heightmap.jpg|center]]<br /> <br /> Jede andere funktioniert natürlich auch, wie z.B. die, aus meinem letzten Tutorial. Der Algorithmus liefert zusammen mit den Oben gezeigten Grundtexturen dieses Bild: <br /> <br /> [[Bild:Tutorial_Terrain2_proctex.jpg|center]]<br /> <br /> ==Das Spiel von Licht und Schatten==<br /> <br /> Wir könnten damit jetzt unsere Welt überziehen. Was dann aber noch fehlt ist Licht und Schatten. Wir wollen Ambient Light und Diffuse Light zum Einsatz kommen lassen. Die Typische Formel zum Berechnen ist:<br /> <br /> '''Intensity=Ambient + Diffuse * (L • N)'''<br /> <br /> '''L''' ist ein Vektor zur Lichtquelle, '''N''' die Flachennormale. '''Ambient''' und '''Diffuse''' die Stärken der jeweiligen Lichttypen. Wir wollen abermals alle Punkte der Heightmap durchgehen und unser Ergebnis in '''LightMaptex''' ablegen. Wenn ein Punkt nicht im Schatten eines anderen liegt, wird sein Farbwert mithilfe obiger Formel berechnet, ansonsten bekommt der Punkt den Farbwert des Ambient Light zugewiesen. <br /> <br /> ===Die Normal Map===<br /> <br /> Bevor wir loslegen, legen wir eine Normal Map an, deren Inhalt alle Normalen der Heightmap ist. Diese Komprimieren wir gleich auf Bytes, damit sie nicht Unmengen an Platz beansprucht. Leider kann man die Normalen nur schlecht für einzelne Punkte direkt berechnen, nehmen also Flächen zur Hilfe. Damit die Sache rund wird, betrachten wir aber nicht nur eine Fläche, sondern gleich alle anliegenden und berechnen daraus einen Normalendurchschnitt.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> ...<br /> type<br /> TNormalMap = Array of Array[0..2] of ShortInt;<br /> ...<br /> <br /> procedure CreateNormalMap(HM : TBitMap; HeightScale : Single;<br /> var NormalMap : TNormalMap);<br /> begin<br /> ...<br /> end;<br /> ...<br /> var<br /> NormalMap : TNormalMap;<br /> HeightMapScale : Single;<br /> NormalMap : TNormalMap;<br /> <br /> begin<br /> Sun[0] := Cos(LightRotation.Position*Pi/180);<br /> Sun[1] := (LightHeight.Max - LightHeight.Position)/100;<br /> Sun[2] := Sin(LightRotation.Position*Pi/180);<br /> HeightMapScale := HeightScaleEdit.Value;<br /> <br /> LightMapTex.Width := HeightMap.Width;<br /> LightMapTex.Height := HeightMap.Height;<br /> <br /> CreateNormalMap(HeightMap, HeightMapScale, NormalMap);<br /> <br /> CreateLightMap(HeightMap, HeightMapScale, NormalMap, Sun, LightMapTex,<br /> AmbientLight.Position / 100, DiffuseLight.Position/100,<br /> RaytracingCheckBox.Checked)<br /> end;<br /> &lt;/source&gt;<br /> <br /> Dies stellt erst einmal ein Grundgerust dar. Statt einer einzelnen Beschreibung der einzelnen UI Komponenten folgendes Bild: <br /> <br /> [[Bild:Tutorial_Terrain2_lightedit.jpg|center]]<br /> <br /> Nun also zur Funktion '''CreateNormalMap'''. Wie gesagt berechnen wir den Durchschnitt der Anliegenden Normalen. Folgendes Schaubild soll die verwendeten Flächen verdeutlichen, wobei '''v0''' das derzeit betrachtete Vertex ist, alle anderen '''vxs''' anliegende:<br /> <br /> v8<br /> v7•--•--•v1<br /> |8 /|1 /|<br /> | / | / |<br /> |/ 7|/ 2|<br /> v6•-v0•--•v2<br /> |6 /|3 /|<br /> | / | / |<br /> |/ 5|/ 4|<br /> v5•--•--•v3<br /> v4<br /> <br /> Mit dem Vektor Kreuzprodukt werden die Normalen für die 8 Flachen berechnet, zusammengezahlt und normiert:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure CreateNormalMap(HM : TBitMap; HeightScale : Single;<br /> var NormalMap : TNormalMap);<br /> const<br /> VertexPoss : Array[0..8] of Array[0..1] of ShortInt =<br /> ((0,0),(1,-1),(1,0),(1,1),(0,1),(-1,1),(-1,0),(-1,-1),(0,-1));<br /> Faces : Array[0..7] of Array[0..2] of Byte =<br /> ((0,1,8),(0,2,1),(0,4,2),(4,3,2),(0,5,4),(0,6,5),(0,8,6),(8,7,6));<br /> var<br /> X,Z : LongInt;<br /> I : LongInt;<br /> <br /> Vertieces : Array[0..8] of TVertex;<br /> Normals : Array[0..7] of TVertex;<br /> begin<br /> SetLength(NormalMap, HM.Width*HM.Height);<br /> FillChar(Vertieces[0,0], SizeOf(Vertieces), 0);<br /> for Z := 0 to HM.Height - 1 do<br /> for X := 0 to HM.Width - 1 do<br /> begin<br /> //Vertieces holen<br /> for I := 0 to 8 do<br /> begin<br /> Vertieces[I][0] := X + VertexPoss[I][0]*VertexPosMultiply;<br /> Vertieces[I][2] := Z + VertexPoss[I][1]*VertexPosMultiply;<br /> Vertieces[I][1] := HM.Canvas.Pixels[X + VertexPoss[I][0], Z +<br /> VertexPoss[I][1]]<br /> /clWhite*255*HeightScale<br /> end;<br /> //Normalen holen<br /> for I := 0 to 7 do<br /> begin<br /> Normals[I] := VectorCrossProduct(<br /> VectorNormalize(VectorSubtract(Vertieces[Faces[I][0]],<br /> Vertieces[Faces[I][1]])),<br /> VectorNormalize(VectorSubtract(Vertieces[Faces[I][1]],<br /> Vertieces[Faces[I][2]])));<br /> Normals[I] := VectorNormalize(Normals[I])<br /> end;<br /> //Den &quot;Durchschnittsvektor&quot;...<br /> for I := 1 to 7 do<br /> Normals[0] := VectorAdd(Normals[0], Normals[I]);<br /> Normals[0] := VectorScale(VectorNormalize(Normals[0]),127.0);<br /> NormalMap[Z*(HM.Height) + X][0] := Trunc(Normals[0][0]);<br /> NormalMap[Z*(HM.Height) + X][1] := Trunc(Normals[0][1]);<br /> NormalMap[Z*(HM.Height) + X][2] := Trunc(Normals[0][2])<br /> end<br /> end;<br /> &lt;/source&gt;<br /> <br /> <br /> ===Es werde Licht===<br /> <br /> Jetzt sind wir soweit. Wir konnen jetzt mit Hilfe unserer Formel fur jeden Punkt die Beleuchtung berechnen. Wie immer: Alle Punkte durchgehen, berechnen: <br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure CreateLightMap(HM : TBitMap; HeightMapScale : Single;<br /> NormalMap : TNormalMap; Sun : TVertex; LightMap : TBitMap;<br /> LightAmbient, LightDiffuse : Single; Raytracing : Boolean);<br /> <br /> type<br /> TRay = record<br /> Origin, Direction : TVertex<br /> end;<br /> <br /> var<br /> HeightMapData : Array of Array of byte;<br /> <br /> procedure PrecacheHeightmap;<br /> var<br /> X,Z : LongInt;<br /> begin<br /> //Läd die Heightmap in ein Delphi Array<br /> SetLength(HeightMapData, HM.Width);<br /> for X := 0 to Length(HeightMapData) -1 do<br /> SetLength(HeightMapData[X], HM.Height);<br /> <br /> for Z := 0 to HM.Height - 1 do<br /> for X := 0 to HM.Width - 1 do<br /> HeightMapData[X,Z] := Trunc(HM.Canvas.Pixels[X,Z]/clWhite * 255)<br /> end;<br /> <br /> function RayIntersected(Ray : TRay; HM : TBitMap;<br /> HeightMapScale : Single):Boolean;<br /> begin<br /> Result := False;<br /> end;<br /> <br /> var<br /> X,Z : LongInt;<br /> Ray : TRay;<br /> n : TVertex;<br /> f : Single;<br /> begin<br /> if Raytracing then PrecacheHeightmap;<br /> <br /> //Wir haben paraleles Licht, also bleibt der Richtungsvektor des<br /> //Rays immer gleich<br /> Ray.Direction := VectorNormalize(Sun);<br /> <br /> <br /> for Z := 0 to HM.Height - 1 do<br /> for X := 0 to HM.Width - 1 do<br /> begin<br /> Ray.Origin[0] := X;<br /> Ray.Origin[1] := HM.Canvas.Pixels[X,Z]/clWhite*255*HeightMapScale;<br /> Ray.Origin[2] := Z;<br /> if RayTracing and RayIntersected(Ray, HM, HeightMapScale) then<br /> f := LightAmbient<br /> else begin<br /> //Komprimierte Normale zurückverwandeln<br /> n[0] := NormalMap[Z*(HM.Height) + X][0];<br /> n[1] := NormalMap[Z*(HM.Height) + X][1];<br /> n[2] := NormalMap[Z*(HM.Height) + X][2];<br /> <br /> f := LightAmbient+LightDiffuse*(VectorDotProduct(<br /> VectorNormalize(n),VectorNormalize(Ray.Direction)));<br /> //Zuviel licht?<br /> if f &gt; 1.0 then f := 1.0;<br /> if f &lt; 0.0 then f := 0.0<br /> end;<br /> LightMap.Canvas.Pixels[X,Z] := RGB(Trunc(f*255),<br /> Trunc(f*255),<br /> Trunc(f*255))<br /> end<br /> end;<br /> &lt;/source&gt;<br /> <br /> Argh.... Wieder so ein Monster an Code! Naja, kämpfen wir uns der Reihe mach durch... In '''HeightMapData''' wird die Heightmap geladen, um schnelleren Zugriff auf sie zu haben (zur Erinnerung an das 1. Tutorial: GDI Befehle sind arsch langsam). Die entstandenen Daten werden von '''RayIntersected''' verwendet um schneller ausführbar zu sein (glaubt mir, hier ist das wirklich nötig!). '''RayIntersected''' selbst gibt bisher immer False züruck (wir werden das spater noch ändern), was bedeutet, auf den derzeit betrachteten Punkt wird kein Schatten geworfen. <br /> <br /> Bevor ich weitermache erläutere ich kurz das Prinzip von Ray Tracern (z.B.: [http://www.povray.org POV-Ray]). Ein Ray ist ein Strahl, der von einem bestimmten Punkt (Origin) losgeschickt, in eine bestimmte Richtung (Direction). Das Tracing, also das abgehen des Rays wird die Funktion '''RayIntersected''' für uns übernehmen. <br /> <br /> Die Richtung des Rays ist fur alle Punkte gleich, da die Sonne zur Erde einen so großen Abstand hat, dass Licht parallel einfällt. Wird ein Ray geschnitten, wird dem Punkt Origin der Wert des Ambient Light zugewiesen, ansonsten wird mit der vorhin vorgestellten Formel die stärke des einfallenden Lichtes berechnet. <br /> <br /> Dies ist noch nichts besonderes, denn OpenGL berechnet das Licht auf ähnliche Weise. Was noch fehlt sind die Schatten. Wollen wir also ein wenig über '''RayIntersected''' nachdenken...<br /> <br /> ===Schattenspiele===<br /> <br /> Wir haben also den Ray. Der Einfachheit halber, gehen wir diesen immer ein Stücken weiter, schauen ob die Höhe der Heightmap gröser ist als der Ray oder nicht, solange bis wir am Ende der Karte angelangt sind. Klingt simpel? Ist es.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> function RayIntersected(Ray : TRay; HM : TBitMap;<br /> HeightMapScale : Single):Boolean;<br /> var<br /> Position : TVertex;<br /> Vor : TVertex;<br /> begin<br /> Result := False;<br /> Position := Ray.Origin;<br /> Vor := VectorNormalize(Ray.Direction);<br /> Position := VectorAdd(Position, Vor);<br /> while (Position[0] &gt; 0) and (Position[0] &lt; HM.Width - 1) and<br /> (Position[2] &gt; 0) and (Position[2] &lt; HM.Height - 1) do<br /> begin<br /> if HeightMapData[Trunc(Position[0]), Trunc(Position[2])]*<br /> HeightMapScale &gt;= Position[1] then<br /> begin<br /> Result := True;<br /> Break<br /> end;<br /> Position := VectorAdd(Position, Vor)<br /> end<br /> end;<br /> (*Achtung: In diesem Codestück ist eine kleine Performancebremse eingebaut. <br /> Wer sie findet kommt deutlich schneller an die ersehnte Textur. <br /> Es handelt sich übrigens um eine fehlende Bedingung im while. *)<br /> &lt;/source&gt;<br /> <br /> Das entlanglaufen des Rays ist nich unbedingt Ideal gelöst, aber es erfüllt seinen Zweck. Starten wir einmal unseren nun fertigen Lightmap Generator und betrachten das Ergebnis: <br /> <br /> [[Bild:Tutorial_Terrain2_lightmap.jpg|center]]<br /> <br /> Diese kann man dann mit der Procedural Texture verknupfen... Je Heller ein Punkt in der Lightmap, desto mehr wird von den Farben der Procedural Texture genommen:<br /> <br /> [[Bild:Tutorial_Terrain2_combined.jpg|center]]<br /> <br /> ==Nachwort==<br /> Aha, du hast also durchgehalten. Ich hoffe jetzt bald viele schone Landschaften mit Schatten zu sehen. Bin jetzt etwas geschafft vom vielen Tippen.<br /> <br /> ...have a lot of fun!<br /> <br /> DelphiC<br /> <br /> == Dateien ==<br /> * {{ArchivLink|file=tut_terrain2_src_vcl‎|text=Beispiel-Quelltext}}<br /> * {{ArchivLink|file=tut_terrain2_exe‎|text=Beispiel-Programm}}<br /> <br /> <br /> {{TUTORIAL_NAVIGATION|[[Tutorial_Terrain1]]|[[Tutorial_Terrain3]]}}<br /> <br /> [[Kategorie:Tutorial|Terrain2]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Terrain1&diff=23929 2009-07-23T15:10:18Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>=Heightmaps - Außenlandschaften mit System=<br /> <br /> ==Vorwort==<br /> <br /> Hi,<br /> <br /> dies Tutorial wird euch in die Basics des Terrain Rendering einweisen. Ich<br /> werde euch zeigen, wie man am Besten mit Heightmaps umgeht und wie man sie<br /> rendert. Daneben werde ich euch auch verraten, wie man mithilfe einer<br /> [[Skybox]] der Szene etwas mehr<br /> Atmosphäre verleiht.<br /> <br /> ==Vorarbeit==<br /> <br /> Für dieses kleine Demo habe ich die OpenGl Bibliothek 1.2 von Mike Lischke<br /> verwendet (OpenGL12.pas). Dazu eine für 3DNow! optimierte<br /> Geometry.pas eingebunden, die aus der GlScene Komponentensammlung stammt<br /> (alle Dateien liegen den Sources bei). Zum Laden der Textur kommt<br /> noch die GlAux Library zum Einsatz, was ihr besser nicht nachmacht,<br /> weils schrecklich alt ist und lang nicht mehr gepflegt wurde. Als <br /> moderne Alternative wäre da z.B. [[Glbitmap_loader|Glbitmap]] zu nennen. <br /> Gerendert wird im OnIdle-Event der Anwendung, aber schaut bei Fragen<br /> doch einfach selbst hinein.<br /> <br /> ===Etwas Atmosphäre bitte===<br /> <br /> Widmen wir uns zunächst einmal dem Himmel. Wenn gerade brauchbares Wetter<br /> ist, dann schaut einfach mal hoch (Solltet ihr jetzt die Decke eines Zimmers<br /> erblicken, dann hop hop, raus an die Frische Luft! Wenns geht Laptop gleich <br /> mitnehmen, an der frischen Luft machts gleich dreimal soviel Spaß!).<br /> Nun, was seht ihr? Ich sehe blauen Himmel, Wolken,... Nix unbekanntes<br /> jedenfalls. Das wollen wir doch gleich mal in OpenGl nachbauen... Wir<br /> nehmen einen Würfel (die schon angekündigte [[Skybox]]), <br /> den wir von innen anschauen und bekleben den mithübschen Bildchen, <br /> die unseren Himmel darstellen.<br /> <br /> Zum erzeugen entsprechender Bilder können wir uns einer Kamera oder einiger<br /> kleiner Softwaretools bedienen. Ich mache letzteres und verweise mal <br /> auf die Programme Terragenund Bryce. Was<br /> wir brauchen sind sechs Bilder. Eines von oben, eines von unten und je eines<br /> für die 4 Himmelsrichtungen. Macht zusammen, ganz nach Adam Riese, 6. <br /> Ich habe mir die Arbeit bereits gemacht, ihr müsst euch also nicht abrackern und<br /> könnt für erste Gehversuche meine Bilder nehmen,. An der Texturauflösung <br /> solltet ihr nicht zu sehr sparen, immerhin ist die [[Skybox]] statisch und man<br /> hat sie doch recht häufig vor der Nase. Also ruhig klotzen statt kleckern, damits<br /> keine klötzchen gibt. <br /> Ich habe ürsprünglich eine Auflösung von 512x512 gewählt, wobei da ruhig mit<br /> der Zeit gegangen werden darf und mit jeder Grafikkartengeneration ist schließlich<br /> mehr Platz im Speicher. Trotzdem kann der Einsatz von [[Textur#Kompressionen|Texturkompression]]<br /> nicht schaden.<br /> <br /> Auf dem Einkaufszettelchen steht also: <br /> * ein unbelichteter Würfel.<br /> * Sechs geladene [[Textur|Texturen]]. <br /> <br /> Um das Verständnis meines Codes ein bischen zu erhöhen, gibts ein wenig<br /> von dem Framework, in das wir unsere [[Skybox]] einpflegen wollen<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> SkyBoxTexturen : Array[0..5] of TGlUInt;<br /> ...<br /> procedure TSkyBoxForm.ApplicationEventsIdle(Sender: TObject;<br /> var Done: Boolean);<br /> <br /> procedure PaintSkyBox;<br /> begin<br /> ...<br /> end; (*PaintSkyBox*)<br /> <br /> var<br /> Error : LongInt;<br /> begin<br /> Done := True;<br /> if not OpenGLInitialized then Exit;<br /> Done := False;<br /> glClear(GL_DEPTH_BUFFER_BIT or GL_COLOR_BUFFER_BIT);<br /> glLoadIdentity;<br /> glRotatef(XRotation, 1, 0,0);<br /> glRotatef(YRotation, 0, 1,0);<br /> PaintSkyBox;<br /> //Error Handler<br /> Error := glgetError;<br /> if Error &lt;&gt; GL_NO_ERROR then<br /> begin<br /> MessageBeep(65535);<br /> Caption := gluErrorString(Error)<br /> end;<br /> //FrameCounter<br /> Inc(Frames);<br /> if GetTickCount - StartTick &gt;=1000 then<br /> begin<br /> Caption := Format('Sky Box Demo FPS: %f',<br /> [Frames/(GetTickCount - StartTick)*1000]);<br /> Frames := 0;<br /> StartTick := GetTickCount<br /> end;<br /> SwapBuffers(Canvas.Handle)<br /> end; (*ApplicationEventsIdle*)<br /> &lt;/source&gt;<br /> <br /> Wenn OpenGL noch nicht initialisiert wurde, wird<br /> abgebrochen. Ansonsten werden die [[glClear|Puffer geleert]] und die [[glLoadIdentity|Einheitsmatrix]]<br /> geladen, die [[Tutorial_Kamera1|Kamera]] gedreht, die Skybox gemalt, auf Fehler geprüft und<br /> die Leistung gemessen.<br /> <br /> Und wie zeichnen wir jetzt die [[Skybox]]? Zuerst sollten wir festlegen, wie<br /> die [[Textur|Texturen]] in unserem Array abgelegt werden. Und weil ich hier<br /> der Capo bin, entscheide ich unumstürzlich: Norden, Osten, Süden, <br /> Westen, Oben und Unten. Mit diesen<br /> [[Textur|Texturen]] wird ein Würfel der Kantenlänge 4 bemalt. <br /> Eine Länge von 2 wäre bescheiden, da in der Demo die nahe Clipping Plane <br /> eine Entfernung von 1 zum Betrachter hat und mir ist es im echten Leben noch<br /> nie passiert, dass der Himmel abgeschnitten erscheint. Warum also sollte ich das<br /> dann in einem OpenGl_Programm provozieren? Zum Zeichnen <br /> definieren wir uns ein Array, welches die 4 Vertices jeder Wand des Würfels<br /> beschreibt.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure PaintSkyBox;<br /> const<br /> QuadPosition : Array[0..5] of Array[0..3] of Array[0..2] of Single =<br /> (((2.005,2.005,-1.995),(2.005,-2.005,-1.995),(-2.005,-2.005,-1.995),<br /> (-2.005,2.005,-1.995)), //Nordseite<br /> ((1.995,2.005,2),(1.995,-2.005,2),(1.995,-2.005,-2),<br /> (1.995,2.005,-2)), //Ostseite<br /> ((-2.005,2.005,1.995),(-2.005,-2.005, 1.995),(2.005,-2.005,1.995),<br /> (2.005,2.005,1.995)), //Südseite<br /> ((-1.995,2.005,-2),(-1.995,-2.005,-2),(-1.995,-2.005,2),<br /> (-1.995,2.005,2)), //Westseite<br /> ((-2,2,-2),(-2,2,2),(2,2,2), (2,2,-2)), //Oberseite<br /> ((2,-2,-2),(2,-2,2),(-2,-2,2),(-2,-2,-2))); //Unterseite<br /> &lt;/source&gt;<br /> <br /> Was erzählt jetzt der für einen Mist? Das ist kein anständiger Würfel, der kann<br /> doch wohl nicht die Ecken alle so unsystematisch wählen. Oder doch? Schau mer<br /> nochmal genauer hin:<br /> Die etwas abgearteten Werte sind alle nahe an 2. Sie sind nötig,<br /> da OpenGL sich ein klein wenig &quot;verrechnet&quot;, was bei genauen Werten Streifen erzeugen<br /> kann. Um dies zu umgehen, werden die vier Himmelrichtungen etwas<br /> näher an den Betrachter gezogen und gleichzeitig etwas gestreckt. Jetzt<br /> noch Texturkoordinaten pro Vertex und einige andere Variablen<br /> definieren:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> TexturePos : Array[0..3] of Array[0..1] of Single = ((1,1),(1,0),(0, 0),(0, 1));<br /> var<br /> Side, Vertex : Integer;<br /> begin<br /> ...<br /> end; (*PaintSkyBox*)<br /> &lt;/source&gt;<br /> <br /> Und jetzt hat unsere Arraysammelwut doch noch etwas Gutes: Das Zeichnen<br /> geht in einer for-Schleife ganz einfach von der Hand.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glBegin(GL_QUADS);<br /> for Side := 0 to 5 do<br /> begin<br /> //Textur aktivieren<br /> glBindTexture(GL_TEXTURE_2D, SkyBoxTexturen[Side]);<br /> //Ecken und Texturkoordinaten übergeben<br /> for Vertex := 3 downto 0 do<br /> begin<br /> glTexCoord2fv(@TexturePos[Vertex][0]);<br /> glVertex3fv(@QuadPosition[Side][Vertex][0])<br /> end;<br /> end<br /> glEnd()<br /> &lt;/source&gt;<br /> <br /> Und voilà. Schon fertig<br /> <br /> [[Bild:Tutorial_Heightmaps-Aussenlandschaften_mit_System_skyboxdemo.jpg]]<br /> <br /> ==Das System der Heightmaps==<br /> <br /> Das ist jetzt alles schön und toll, aber durch eine 3D-Landschaft kann man<br /> wandeln. In Unserer Skybox dürfen wir uns nur drehen, wie langweilig. Darum<br /> wollen wir uns um eine etwas &quot;tiefergehende&quot;, weniger flache Landschaft bemühen. <br /> <br /> Heightmaps sind Graustufenkarten einer Landschaft, topologische Karten sozusagen. <br /> Je weißer ein Pixel ist, desto höher ist der Punkt in der Landschaft. Die Punkte<br /> wollen wir mit Dreiecken verbinden, die wir schließlich zeichnen wollen.<br /> <br /> ===Die Sache mit dem Bitmap===<br /> <br /> Also her mit so einer Karte! Die könnten wir mit einem Generator wie<br /> [[Perlin Noise]] erzeugen oder, für die ganz wilden, mit einem <br /> Bildbearbeitungsprogramm selbst zeichnen.<br /> Ich packe dagegen eine Heightmap einer echten Landschaft aus, welches ich irgendwo<br /> im Netz aufgetrieben habe:<br /> <br /> [[Bild:Tutorial_Heightmaps-Aussenlandschaften_mit_System_YU14H.jpg]]<br /> <br /> Da das Auslesen der Pixeldaten direkt aus einem Bitmap mithilfe eines<br /> TBitmap eine wirklich sehr,<br /> sehr langsame Angelegenheit ist, sollten wir die Daten zuerst in einem<br /> wesentlich schnelleren Delphi Array zwischenspeichern. Die Größe des Arrays<br /> wählen wir (86+1)x(86+1), ein Viertel der Größe des Bitmaps. Das sollte uns<br /> eigentlich genügen, allein schon, da höhere Auflösungen mehr Rechenzeit<br /> beanspruchen - hey, das Tutorial ist schon ein wenig älter! <br /> Wir sollten auch überlegen, auf welche Größe wir unsere Karte<br /> strecken wollen (eigentlich ist das nicht nötig, will man aber die Auflösung<br /> der Umgebung später erhöhen, ohne dabei die Größe der Map zu verändern, <br /> ist das sinnvoll). Fügen wir also unserem<br /> Code folgende Zeilen hinzu:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> ...<br /> MapSize = 1024;<br /> MapResolution = 86;<br /> <br /> type<br /> TMapDaten = Array[0..MapResolution, 0..MapResolution] of Byte;<br /> <br /> TSkyBoxForm = class(TForm)<br /> ...<br /> private<br /> ...<br /> MapDaten : TMapDaten;<br /> ...<br /> &lt;/source&gt;<br /> <br /> Bevor wir anfangen können zu rendern, müssen wir die Daten aus dem Bitmap<br /> auch noch laden. Ein guter Zeitpunkt dafür wäre im OnShow-Ereignis, in dem<br /> bereits OpenGL initialisiert wird. Fügen wir dort also eine neue Prozedur<br /> ein, die ein Bitmap öffnet und die für uns interessanten Daten in den<br /> MapDaten ablegt:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure LoadHeightMap;<br /> var<br /> Bmp : TBitMap;<br /> X,Z : LongInt;<br /> begin<br /> Bmp := TBitMap.Create;<br /> try<br /> Bmp.LoadFromFile('YU14H.bmp');<br /> //Bitmap in MapDaten laden...<br /> for X := 0 to MapResolution do<br /> for Z := 0 to MapResolution do<br /> MapDaten[X,Z] := Trunc(Bmp.Canvas.Pixels<br /> [Trunc(X/MapResolution*Bmp.Width),<br /> Trunc(Z/MapResolution*Bmp.Height)]<br /> / clWhite * 255)<br /> except<br /> MessageDlg('Fehler beim laden der Heightmap', mtError, [mbOk], 0)<br /> end;<br /> Bmp.Free<br /> end; (*LoadHeightMap*)<br /> &lt;/source&gt;<br /> <br /> Benutzt man die Scanline Funktion von TBitmap, ein bischen <br /> Pointerarithmetik und ein fest vorgegebenes Pixelformat im Bitmap, <br /> dann kann man das noch billiger haben.<br /> <br /> Ich denke, das meiste erklärt sich bereits von selbst. Die Zeile<br /> MapDaten[X,Z] := ... bedarf möglicherweise etwas genaueren Erläuterungen. Da<br /> jeder Eintrag in MapDaten genau ein Byte groß ist, dürfen die eingesetzten<br /> Werte nur im Bereich 0 bis 255 liegen. Wenn wir uns aber die Farbe eines<br /> Pixels aus dem Bitmap holen, sind in ihm Werte für Blau, Rot und Grün<br /> enthalten (Für jede Farbe wird 1 Byte verwendet. Das sind dann 3 Byte, nicht<br /> 1). Durch Teilen durch clWhite erhalten wir den Weißheitsgrad in Prozent.<br /> Multiplizieren wir den erhaltenen Wert mit 255, landen wir im gewünschten<br /> Bereich zwischen 0 und 255. Da der Wert jetzt aber noch ein Single ist, wir<br /> aber ein Byte brauchen, schneiden wir den nichtganzzahligen Anteil einfach ab. <br /> Beim Zugriff auf das Pixel machen wirs wieder genauso. Da hat sichs dann wieder<br /> gerächt, daß MapDaten eine andere Auflösung hat, als das Bitmap. Das merken<br /> wir uns dann gleich mal für später geschriebene Heightmap-Renderer, gell?<br /> <br /> ===Rendern der Heightmap===<br /> <br /> Ach ja, gezeichnet werden will der Kram ja jetzt auch noch. Wie war das?<br /> Dreiecke wollten wir nehmen? Die Höhen können wir ja jetzt aus MapDaten<br /> nehmen, sonst hätte sich der Aufwandt da oben mal echt nicht gelohnt. <br /> <br /> [[Bild:Tutorial_Heightmaps-Aussenlandschaften_mit_System_triangle-grid.gif]]<br /> <br /> Grid abgehen, Dreiecke zeichnen, nächster Gridpunkt..., danach siehts<br /> jedenfalls aus.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure PaintHeightMap;<br /> const<br /> VertPos : Array[0..3] of Array[0..1] of Byte =<br /> ((0,0),(0,1),(1,1),(1,0));<br /> var<br /> X,Z,I : LongInt;<br /> Vertieces : Array[0..3] of TVertex;<br /> <br /> procedure PaintTriangle(V1, V2, V3 : Integer);<br /> var<br /> Normale : TVertex;<br /> begin<br /> Inc(Triangles);<br /> //Flächennormale berechnen<br /> Normale := VectorCrossProduct(<br /> VectorSubtract(Vertieces[V1], Vertieces[V2]),<br /> VectorSubtract(Vertieces[V2], Vertieces[V3]));<br /> NormalizeVector(Normale);<br /> //Dreieck zeichnen<br /> glNormal3fv(@Normale[0]);<br /> glBegin(GL_TRIANGLES);<br /> glVertex3fv(@Vertieces[V1][0]);<br /> glVertex3fv(@Vertieces[V2][0]);<br /> glVertex3fv(@Vertieces[V3][0]);<br /> glEnd()<br /> end; (*PaintTriangle*)<br /> <br /> begin<br /> for X := 0 to MapResolution - 1 do<br /> for Z := 0 to MapResolution - 1 do<br /> begin<br /> //Alle Vertieces erzeugen<br /> for I := 0 to 3 do<br /> begin<br /> Vertieces[I][0] := (X + VertPos[I][0])/MapResolution*MapSize;<br /> Vertieces[I][2] := (Z + VertPos[I][1])/MapResolution*MapSize;<br /> Vertieces[I][1] := MapDaten[X + VertPos[I][0],Z + VertPos[I][1]]<br /> end;<br /> PaintTriangle(0,1,3);<br /> PaintTriangle(1,2,3)<br /> end<br /> end; (*PaintHeightMap*)<br /> &lt;/source&gt;<br /> <br /> Was passiert genau? Die Gridpunkte werden der Reihe nach<br /> abgegangen. An jedem werden die Orte der vier anliegenden Vertices berechnet<br /> und schließlich mit PaintTriangle zwei Dreiecke gezeichnet, welches zuerst die<br /> Flächennormale fürs [[Tutorial_Lektion_8|Licht]] berechnet und dann die Koordinaten an<br /> OpenGL weiterreicht. Und nicht vergessen, die [[Skybox]] verträgt das Licht nicht ganz<br /> so gut, weil deren Licht ist ja bereits durch die Texturen bestimmt.<br /> Was wir noch bedenken müssen ist, daß nach dem Aufruf von PaintSkyBox der [[Tiefenpuffer]] geleert<br /> werden muss. Alternativ könnten wir vor dem Zeichnen der [[Skybox]] auch mit [[glDepthMask]] das Schreiben<br /> in den Tiefenpuffer unterbinden und danach wieder anschalten.<br /> <br /> Der Lohn der Müh::<br /> <br /> [[Bild:Tutorial_Heightmaps-Aussenlandschaften_mit_System_ergebnis.jpg]]<br /> <br /> ==Workshop==<br /> <br /> Um euer Hirn noch ein wenig zu belasten, habe ich noch eine Idee zur Erweiterung des kleinen Programms:<br /> Die Landschaft kann mit einer Textur überzogen werden, dann ist sie nicht ganz so langweilig<br /> grau. Details? [[Tutorial_Terrain2|Hier]]!<br /> <br /> Und jetzt? Kann ich mich nur noch verabschieden...<br /> Euer<br /> <br /> Delphic<br /> <br /> == Dateien ==<br /> * {{ArchivLink|file=tut_terrain1_src_vcl|text=Beispiel-Quelltext (Delphi)}}<br /> <br /> {{TUTORIAL_NAVIGATION|-|[[Tutorial_Terrain2]]}}<br /> <br /> [[Kategorie:Tutorial|Terrain1]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Nachsitzen&diff=23928 2009-07-23T15:09:55Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>==Vorwort==<br /> Immer wieder muss ich feststellen, dass viele, die (mit OpenGl) 3D Anwendungen schreiben, nichts mit der Mathematik dahinter anfangen können. Um das Ein oder Andere zu verstehen oder sich selbst überlegen zu können, ist dieses Wissen aber unabdingbar. Ich möchte mit diesem Artikel helfen, diesen Zustand zu beenden und entsprechends Wissen unter euch verbreiten. Dies und <br /> das werded ihr aus der Schule kennen, wenn ihr also etwas überspringen wollt, orientiert euch an den Überschriften.<br /> <br /> ==Trigonometrie am rechtwinkligen Dreieck==<br /> Man stelle sich vor, man hat einen Kreis, mit Radius 1. Der Mittelpunkt des Kreises befindet sich auf dem Koordinatensystem Ursprung. An der X-Achse ist ein Winkel ß angetragen:<br /> <br /> [[Bild:Tutorial_Nachsitzen_einheitskreis.gif]]<br /> <br /> An der x-Achse bildet sich dann ein rechter Winkel (wichtig für normale Trigonometrie). Die diesem Winkel gegenüberliegende Seite(r) nennt man Hypotenuse. Die am Winkel ß anliegende Seite(x) ist die Ankathete. Die dem Winkel gegenüberliegende Seite(y) heißt Gegenkathete. Man definiert folgende Funktionen:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> sin(ß) = Gegenkathete / Hypotenuse<br /> cos(ß) = Ankathete / Hypotenuse<br /> tan(ß) = Gegenkathete / Ankathete<br /> &lt;/source&gt;<br /> <br /> Im Einheitskreis(und nur dort) gilt:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> sin(ß) = y<br /> cos(ß) = x<br /> &lt;/source&gt;<br /> da die Länge der Hypotenuse 1 ist(Kreisradius).<br /> <br /> Die Umkehrfunktionen dazu sind (in Pascal):<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> ß = arcsin(sin(ß))<br /> ß = arccos(cos(ß))<br /> ß = arctan(tan(ß))<br /> &lt;/source&gt;<br /> <br /> für ß im Bereich 0° - 90°. In den anderen Quadranten des Koordinatensystems, sind die Umkehrfunktionen nicht für alle Winkel eindeutig zurückzurechnen, hier muss man also ein wenig aufpassen, z.B. gibt arcsin(sin(ß)) im Bereich 90°-180° den Winkel 180° - ß aus. Im übrigen ist darauf zu achten, dass die FPU im Bogen- und nicht im Gradmaß rechnet. Umgerechnet werden kann wie folgt:<br /> <br /> [[Bild:Tutorial_Lineare_Algebra_deg2rad.png]]<br /> <br /> Für den Umgang mit Sinus und Cosinus gibt es noch ein paar spezielle Formeln, die einem Arbeit abnehmen können:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> sin(-ß) = - sin(ß)<br /> cos(-ß) = cos(ß)<br /> <br /> sin(90° - ß) = cos (ß)<br /> cos(90° - ß) = sin (ß)<br /> <br /> sin²(ß) + cos²(ß) = 1<br /> &lt;/source&gt;<br /> Bei Bedarf stehen weitere in jeder brauchbaren Formelsammlung, aber meist kommt man mit diesen aus.<br /> <br /> Wozu das? Im Kapitel über [[Matrix|Matrizen]] werden wir sehen, dass sich die drei genannten trigononmetrischen Funktionen dazu nutzen lassen, das Koordinatensystem zu drehen; außerdem kann man mithilfe der genannten Formeln sin(ß) = y und cos(ß) = x ganz einfach Kreise zeichnen. Wenn man sich dann überlegt, daß [[Kugel|Kugeln]] im Prinzip nichts anderes sind, als Kreise, die entlang der Z-Achse orthogonal (rechtwinklig zur z-Achse) gezogen werden und die Aussenpunkte dieser Kreise (als Radius gezogen auf der x/y-Ebene), bei entfernter Betrachtung, selbst wieder einen Kreis (hier blau gezeichnet) beschreiben... <br /> <br /> [[Bild:Tutorial_Nachsitzen_KreisKugel.png]]<br /> <br /> Es gibt noch viele weitere Anwendungsmöglichkeiten, gerade die Umkehrfunktionen. So kann man mit Hilfe von Trigonometrie berechnen, um wieviel Grad ein Objekt weiter gedreht werden muss, um in eine bestimmte Richtung zu zeigen. Dreiecke sind generell auch Verdächtige beim Einsatz von Trigonometrie.<br /> <br /> ==Die Welt der Matrizen==<br /> Matrizen gelten als das Handwerkszeugs eines 3D Programmierers. Sie sind, wenn man sie einmal verstanden hat, ein mächtiges Hilfsmittel, das man irgendwann nicht mehr missen mag und kann! Vorher sollten wir aber noch einmal Vertieces in OpenGl (bei D3D läuft es im Prinzip genauso) betrachten und uns erst dann auf Matrizen stürzen.<br /> <br /> ===Vertices und ihr Ursprung===<br /> <br /> Ein Vertex beschreibt einen Punkt im 3D Raum. Man könnte nun annehmen, dass ein Vertex durch 3 Koordinaten x,y,z beschrieben wird. Falsch gedacht, denn die meisten 3D APIs verwenden '''4-Dimensionale''' Vertices(x/y/z/w)?!?<br /> <br /> Ich denke, zu den 3 ersten Koordinaten muss ich nichts weiter sagen, zur w-Koordinate hingegen schon: w ist normalerweise immer 1.0. Mit glVertex4 kann bei Bedarf auch ein anderer Wert zugewiesen werden. Ist w ungleich Null, so wird ein Vertex als folgender 3-Dimensionaler Punkt interpretiert: (x/w, y/w, z/w). Im Normalfall sollte der Wert für w aber auf 1.0 belassen werden, es sei denn man hat eine interessante Idee, die sich mit einem w ungleich 1.0 besonders schön realisieren lässt. Wen die w-Koordinate interessiert, sollte in der OpenGl Spezifikation unter Coordinate Transformations nachschauen.<br /> <br /> Ein Beispiel für die Effekt beim Einsatz von w Koordinaten: Beim ersten Dreieck ist im oberen Punkt w = 1.0, im 2. ist w = 0.5:<br /> <br /> [[Bild:Tutorial_Nachsitzen_wcoord.jpg]]<br /> <br /> ===Einstieg in Matrizen===<br /> Beginnen wir am Anfang mit einer allgemeinen Definition einer Matrix:<br /> <br /> '''Definition''':Eine m x n Matrix ist eine Tabelle aus Werten mit n Spalten und m Zeilen.<br /> <br /> Die in Direct3D und OpenGl Verwendung findenen Matrizen sind generell 4x4 Matrizen, mit Singles als Elemente:<br /> <br /> [[Bild:Tutorial_Nachsitzen_Matrix4x4.png]]<br /> <br /> ===Anwendung der Matrix auf einen Vektor===<br /> <br /> Hat man nun ein 3-Dimensionales Vertex (w=1.0) und möchte diesen durch die Matrix schicken, so rechnet man:<br /> <br /> [[Bild:Tutorial_Nachsitzen_Matrix4x4MulVec.png]]<br /> <br /> Bzw:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> x_neu := x*a[1,1] + y*a[1,2] + z*a[1,3] + w*a[1,4]<br /> {Koeffizienten aus der ersten Zeile der Matrix}<br /> y_neu := x*a[2,1] + y*a[2,2] + z*a[2,3] + w*a[2,4]<br /> {Koeffizienten aus der zweiten Zeile der Matrix}<br /> z_neu := x*a[3,1] + y*a[3,2] + z*a[3,3] + w*a[3,4]<br /> {Koeffizienten aus der dritten Zeile der Matrix}<br /> w_neu := x*a[4,1] + y*a[4,2] + z*a[4,3] + w*a[4,4]<br /> {Koeffizienten aus der letzten Zeile der Matrix}<br /> &lt;/source&gt;<br /> <br /> Wer nun ein Wenig darüber nachdenkt, kommt auf ein Ergebnis:<br /> :'''Die Spalten sind die Bilder der Einheitsvektoren'''<br /> Die Bedeutung dürfte noch nicht klar sein, aber das kommt bald.<br /> <br /> Ist (wie fast immer) w=1, dann beschreibt die letzte Spalte der Matrix eine Verscheibung der Punkte, denn in der obigen Gleichung steht dann<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> x_neu := ... + a[1,4]<br /> y_neu := ... + a[2,4]<br /> z_neu := ... + a[3,4]<br /> w_neu := ... + a[4,4]<br /> &lt;/source&gt;<br /> Es wird dadurch die letzte Spalte auf das Vertex aufaddiert. Für alle hier genannten Matrixoperatoren gilt außerdem, dass a[4,1] = a[4,2] = a[4,3] = 0. Und für a[4,4] und w_neu:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> w_neu = a[4,4] = 1.<br /> &lt;/source&gt;<br /> Klar ist also, dass die w-Koordinate unverändert bleibt - nur Projektionsmatrizen halten sich nicht an diese Regel, aber da liegt genau deren Trick.<br /> <br /> ===Die Identitätsmatrix, oder der Ursprung von glLoadIdentity===<br /> <br /> Eine der wichtigsten Matrizen ist die, die nichts macht. Also ein Vertex dorthin Projeziert, wo es sich bereits am Anfang befand:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> Matrix * V = V<br /> &lt;/source&gt;<br /> Schauen wir zurück, wie eine Matrix auf ein Vertex angewendet wird:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> x_neu := x*a[1,1] + y*a[1,2] + z*a[1,3] + w*a[1,4]<br /> &lt;/source&gt;<br /> Unser Ziel ist, dass x_neu gleich x ist. Das lässt sich immer erreichen, indem wir den Koeffizienten a[1,1] = 1.0 setzen und die restichen = 0. Dann steht da nämlich:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> x_neu := x*1 + y*0 + z*0 + w*0 { = x }<br /> &lt;/source&gt;<br /> Die gleiche Überlegung kann man auch für die Anderen 3 Elemente y,z und w machen. Jede dieser Überlegungen ergibt eine Zeile der Identitätsmatrix. Das Ergebnis:<br /> <br /> [[Bild:Tutorial_Nachsitzen_IdentityMatrix.png]]<br /> <br /> Ausgehend von dieser Matrix kann man sich jetzt weitere Matrizen überlegen:<br /> <br /> ===Welten verschieben===<br /> <br /> Überlebenswichtig in 3D Anwendungen dürften die Translationsmatrizen sein, die ein Vertex verschieben - aber das haben wir ja schon ein paar Zeilen weiter oben geklärt, wie man das durch w=1 und der letzten Spalte der Matrix anstellt.<br /> <br /> [[Bild:Tutorial_Nachsitzen_MoveMatrix.png]]<br /> <br /> ===Um den Ursprung drehen===<br /> <br /> Ein Porsche, den man vor zurück, links, rechts hoch und runterbewegen kann, ist schon was tolles. Deutlich mehr Klasse bekommt er, wenn man ihn auch noch aus verschiedenen Blickwinkeln anschauen und frei drehen kann. Den meisten dürfte damit schon klar sein, worauf ich hinaus will: Drehungen:<br /> <br /> {| border=&quot;1&quot;<br /> |- valign=&quot;top&quot; <br /> | [[Bild:Tutorial_Nachsitzen_rotz.gif]]<br /> | <br /> ====Drehen um die Z-Achse====<br /> <br /> Rotationen zusammenstöpseln geht einfach. Erinnern wir uns an den Satz: &quot;Die Spalten sind die Bilder der Einheitsvektoren&quot;. Mit dieser Hilfe können wir uns jetzt selbst überlegen, wie eine Rotationsmatrix, die um die Z-Achse mit dem Winkel ß dreht, auszusehen hat.<br /> <br /> Gehen wir die Einheitsvektoren der Reihe nach ab:<br /> <br /> Der Z-Achsen Einheitsvektor(0.0, 0.0, 1.0) bleibt bei unserer Rotation unverändert - man nehme einen Finger, deute damit nach vorne. Nun drehe man diesen Finger um seine eigene Achse, wohin zeigt er? In die selbe Richtung wie vor der Drehung? So sollte es zumindest sein, ansonsten habt ihr ein anatomisches Problem ;-). Damit entspricht Z-Achsen Einheitsvektor auch der vorletzen Spalte der Matrix: (0.0, 0.0, 1.0, 0.0)<br /> <br /> Der X-Achsen Einheitsvektor(1.0, 0.0, 0.0) dreht sich hingegen mit. Trigonometrie findet der Lösung Spur. Ein Blick auf das Bild zum Einheitskreis zeigt, dass wir gerade das gleiche Problem für X und Y zu bewältigen haben: Die Rotationsachse ist in beiden Fällen die Z-Achse. Der Einheitsvektor, der gedreht wird, ist der X-Achsen Einheitsvektor also:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> x := cos(ß)<br /> y := sin(ß)<br /> &lt;/source&gt;<br /> womit wir den Inhalt der ersten Spalte der Matrix kennen: (cos(ß); sin(ß); 0; 0)<br /> <br /> Das lässt sich jetzt genauso auf den Y-Achsen Einheitsvektor(0.0, 1.0, 0.0) übertragen, man muss nur bedenken in welcher weise sich x und y vertauschen:<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> x = -sin(ß)<br /> y = cos(ß)<br /> &lt;/source&gt;<br /> So ergibt sich für die zweite Spalte: (-sin(ß); cos(ß); 0; 0)<br /> <br /> Und schließlich können wir eine Matrix für die Drehung um die Z-Achse mit dem Winkel ß beschreiben:<br /> <br /> [[Bild:Tutorial_Nachsitzen_RotZMatrix.png]]<br /> |- valign=&quot;top&quot; <br /> | [[Bild:Tutorial_Nachsitzen_roty.gif]] <br /> |<br /> <br /> ====Drehen um die Y-Achse====<br /> <br /> Wenn man nun auf die gleiche Weise an die weiteren Drehachsen herangeht, so wird man auf dieses Ergebnis kommen:<br /> <br /> [[Bild:Tutorial_Nachsitzen_RotYMatrix.png]]<br /> |- valign=&quot;top&quot; <br /> | [[Bild:Tutorial_Nachsitzen_rotx.gif]]<br /> |<br /> ====Drehen um die X-Achse====<br /> <br /> [[Bild:Tutorial_Nachsitzen_RotXMatrix.png]]<br /> |}<br /> <br /> ===Matrixoperationen===<br /> <br /> Fürs Arbeiten mit Matrizen gibt es ein paar wichtige Operationen. Ohne diese macht das Arbeiten wenig Spass und würde einem auch wenig bringen.<br /> <br /> Ich möchte hier keine genaue Erläuterung über die Funktionsweise dieser Operationen geben, aber erklären, was sie tun und was man damit anstellen kann. Wer diese Operationen verwenden möchte, sollte mal auf Mike Lischkes Homepage vorbeischaun. Dort findet ihr eine Geometry.pas, die diese Funktionen und noch viele mehr beinhaltet. Eine etwas verbesserte und immer wieder aktualisierte Variante liegt dem glScene Projekt bei. Mathematische Details findet ihr in unseren Wiki-Artikeln [[Matrix]] und [[Techniken_zur_Matrixinversion]].<br /> <br /> ===Matrixmultiplikation===<br /> <br /> Eine wichtige Operation ist die Matrixmultiplikation. Sie verbindet zwei Matrizen zu einer so, dass sie nacheinander ausgeführt werden. Dabei ist zu bedenken, dass die Reihenfolge einen Unterschied macht: erst drehen und dann verschieben ist ungleich erst verschieben und dann drehen, aber das solltet ihr bei der Verwendung von glRotate und glTranslate längst bemerkt haben.<br /> <br /> Nun wie multipliziert man Matrizen miteinander? Wie wollen M mit M' multiplizieren. Die Spalten von M' kann man als Vektoren auffassen. Also wendet man einfach M auf die Spalten von M' und bekommt dabei 4 Vektoren. Diese setzt man wieder in einer neuen Matrix nebeneinander und schon hat man M mit M' multipliziert. Ausführlicher wie gesagt im [[Matrix]] Artikel.<br /> <br /> ===Matrixinversion===<br /> <br /> Eine invertierte Matrix macht genau das Gegenteil der ursprünglichen Matrix. Verschiebt die ursprüngliche ein Vertex um 3 nach rechts, so schiebt die intervtierte Matrix ein Vertex um 3 nach links (Achtung: nicht alle Matrizen sind invertierbar, Rotations- und Translationsmatrizen lassen sich jedoch immer invertieren). Dies lässt sich sinnvoll bei Kameras einsetzen:<br /> <br /> Man hat ein Objekt, dessen Rotation durch eine Matrix beschrieben wird, was generell sinnvoll ist, wenn das Objekt voneinander abhängige Drehungen vollführen soll oder man das lokale Koordinatensystem des Objekts benötigt. Jedenfalls will man nun das Objekt nicht von aussen bestaunen, sondern sich in die Ansicht des Objekts selbst hineinversetzen, so kann man dessen Rotationsmatrix einfach invertieren und schon hat man sein Ziel erreicht. Wen ähnliches interessiert, sollte sich jetzt einmal an mein [[Tutorial_Kamera1|Kamera Tutorial]] wagen und schauen, dass er's versteht.<br /> <br /> Für allgemeine Matrizen ist die nötige Rechnerei leider nicht ganz harmlos. Ich empfehle hierzu einen Blick in die Wikipedia unter Inverse Matrix oder bessere Matheformelsammlungen bzw. Geometrie oder Lineare Algebra Skripte. Ist die Matrix dagegen ein Produkt aus Verschiebungen und Rotationen, dann langt bereits der Artikel [[Techniken_zur_Matrixinversion]].<br /> <br /> ==OpenGl, Direct3D, IrixGl, MesaGl,... und das Thema Matrizen==<br /> <br /> Wie hat man sich gefreut, als man glaubt Matrizen endlich ein wenig verstanden zu haben und dann das! Die ersten Versuche mit [[glLoadMatrix]] und [[glMultMatrix]] müssen zwingend schiefgehen. Immer, wenn man nicht vorgewarnt wird. Wer glaubt seine Matrizen einfach mit einem 2 Dimensionalen Array beschreiben zu können irrt. Die Idee ist zwar nicht schlecht, aber aus Performancegründen liegen die OpenGl Matrizen nicht zeilenweise, sondern spaltenweise im Speicher:<br /> <br /> [[Bild:Tutorial_Nachsitzen_GlMatrix.png]]<br /> <br /> Ich persönlich bevorzuge meist, statt dass ich in einem 2D-Array immer mit den Zugriffsvariablen herumwurschtle, den Zugriff auf die Matrix mit einem eindimensionalen Array. Die obige Tabelle hilft, die passene Zelle zu finden.<br /> <br /> ==Kopfschmerzen?==<br /> <br /> Ahh, wieder eines meiner schrecklichen Tutorials überlebt. Ich hoffe, dass wenigstens ein paar Leute unter euch das ein oder andere Verstanden haben und ich das alles nicht umsonst geschrieben habe (wenns nur einer Verstanden hat, bin ich schon glücklich ;-) ). Ein paar weitere, spannende Hilfsmittel, die hier nicht unerwähnt bleiben sollten, sind das [[Standard_Skalarprodukt|Punktprodukt]] und das [[Vektorprodukt]], welche Hilfsmittel in der Vektorrechung sind. Defizite dort gleicht das Tutorial über [[Tutorial_Lineare_Algebra|Lineare Algebra]] aus.<br /> <br /> ...have a lot of fun!<br /> <br /> Delphic<br /> <br /> <br /> {{TUTORIAL_NAVIGATION| [[Tutorial Lineare Algebra]] | [[Tutorial Objekt gedreht und dennoch nach vorne bewegt]]}}<br /> <br /> [[Kategorie:Tutorial|Nachsitzen]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Abseits_eckiger_Welten&diff=23927 2009-07-23T15:09:26Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>= Abseits eckiger Welten =<br /> == Einführung ==<br /> <br /> Unsere Welt ist, schlecht, eintönig und eckig. Wirklich? Eckig? Schauen wir uns noch einmal um. An vielen Stellen ja, aber nicht überall. Rundungen sind sogar recht häufig anzutreffen. Ein Blick um mich herum offenbart es. Maus, Lampe, Joystick,... Vieles hat Rundungen. Ein Blick auf das was bisher bei DGL zu sehen war, zeigt: alles eckig :-(. Das muss geändert werden. Runden wir unsere Virtuellen Welten ein wenig ab - unser Hilfsmittel: Curved Surfaces<br /> <br /> <br /> == Von Linien und Kurven ==<br /> <br /> Dies Kaptitel basiert auf [http://www.gamasutra.com/features/19990611/bezier_01.htm Curved Surfaces Using Bézier Patches von Gabe Kruger]. Mit freundlicher Genehmigung übersetzt ins deutsche und natürlich mit der ein oder anderen Änderung.<br /> <br /> === Prozedurale Linien ===<br /> <br /> Gerade Strecken lassen sich allein durch die Angabe eines Start und Endpunktes beschreiben. Mit einer Liniengleichung lassen sich beliebig viele Punkte auf dieser Strecke berechnen. Eine solche Gleichung ist z.B.:<br /> <br /> Q(t) = (1 - t)*P&lt;sub&gt;0&lt;/sub&gt; + t*P&lt;sub&gt;1&lt;/sub&gt;<br /> <br /> Der Parameter t hat dabei Werte von 0 bis 1. P&lt;sub&gt;0&lt;/sub&gt; und P&lt;sub&gt;1&lt;/sub&gt; sind die Endpunkte der Strecke. Setzt man den Parameter t = 0 ein, so ist das Ergebnis P&lt;sub&gt;0&lt;/sub&gt;. Setzt man 1 ein ist das Ergebnis P&lt;sub&gt;1&lt;/sub&gt;.<br /> Die Gleichung könnte man etwas umschreiben:<br /> <br /> Q(t) = B&lt;sub&gt;0&lt;/sub&gt;(t)*P&lt;sub&gt;0&lt;/sub&gt; + B&lt;sub&gt;1&lt;/sub&gt;(t)*P&lt;sub&gt;1&lt;/sub&gt;<br /> <br /> Wobei gilt:<br /> <br /> B&lt;sub&gt;0&lt;/sub&gt;(t) = 1 - t<br /> B&lt;sub&gt;1&lt;/sub&gt;(t) = t<br /> <br /> Man nennt B&lt;sub&gt;0&lt;/sub&gt;(t) und B&lt;sub&gt;1&lt;/sub&gt;(t) die Basis Funktionen der Liniengleichung. Ändern wir diese Gleichung nochmals ein wenig ab:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_linearsum.gif]]<br /> <br /> Dies ist die analytisch bearbeitete Fassung der Liniengleichung, die meisten Beschreibungen parametrischer '''Kurven''' werden in dieser Form gezeigt. Kurven? Klingt so als wären wir bereits am Ziel? Fast.<br /> <br /> === Evolution zu Bezier Kurven ===<br /> <br /> Wie erzeugen wir nun eine Kurve in parametrischer Form, ählich der obigen? Wir wollen eine Kurve beschreiben, die durch die Endpunkte geht und dazwischen sich einem anderen Punkt annähert:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_linesconnected.gif]]<br /> <br /> P&lt;sub&gt;0&lt;/sub&gt; und P&lt;sub&gt;2&lt;/sub&gt; sind die Endpunkte, P&lt;sub&gt;1&lt;/sub&gt; ist der Kontrollpunkt, dem wir uns annähern wollen. Man könnte nun einen Punkt P&lt;sub&gt;a&lt;/sub&gt;(t) zwischen P&lt;sub&gt;0&lt;/sub&gt; und P&lt;sub&gt;1&lt;/sub&gt; interpolieren und das gleiche mit einem Punkt P&lt;sub&gt;b&lt;/sub&gt;(t) zwischen P&lt;sub&gt;1&lt;/sub&gt; und P&lt;sub&gt;2&lt;/sub&gt;. Der gewünschte Punkt Q(t) auf der Kurve kann dann errechnet werden, durch interpolieren zwischen den Punkten P&lt;sub&gt;a&lt;/sub&gt; und P&lt;sub&gt;b&lt;/sub&gt;:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_interpolated.gif]]<br /> <br /> In mathematischen Formeln ausgedrückt:<br /> <br /> P&lt;sub&gt;a&lt;/sub&gt;(t) = (1 - t)P&lt;sub&gt;0&lt;/sub&gt; + t * P&lt;sub&gt;1&lt;/sub&gt;<br /> P&lt;sub&gt;b&lt;/sub&gt;(t) = (1 - t)P&lt;sub&gt;1&lt;/sub&gt; + t * P&lt;sub&gt;2&lt;/sub&gt;<br /> <br /> Q(t) = (1 - t)P&lt;sub&gt;a&lt;/sub&gt;(t) + tP&lt;sub&gt;b&lt;/sub&gt;(t) =<br /> = (1 - t)²P&lt;sub&gt;0&lt;/sub&gt; + 2(1 - t)tP&lt;sub&gt;1&lt;/sub&gt; + t²P&lt;sub&gt;2&lt;/sub&gt;<br /> <br /> Der Lohn der Mühen:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_quadraticbezier.gif]]<br /> <br /> Wir können nun die Gleichung von oben umschreiben:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_quadraticsum.gif]]<br /> <br /> Nun haben wir eine Definition einer quadratischen Bézier Kurve entwickelt. Es gibt eine einfache Formel für die Basis Funktionen von Bezier Kurven für einen beliebigen Grad. n ist der Grad, i beziffert die Basis Funktion und reicht damit von 0 bis n:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_basisfunctions.gif]]<br /> <br /> Ein Beispiel einer solchen Kurve mit dem Grad 3:<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_kubikbezier.gif]]<br /> <br /> == Evaluators ==<br /> <br /> Wir können jetzt Bezier Kurven von Hand berechnen und, mit etwas Umsicht das ganze von 2D auf 3D transformieren. Das kann man vielseitig einsetzen und man kann gleichzeitig auf Detaileinstellungen in einem Programm reagieren - je höher der Detailgrad, desto feiner werden die Kurven aufgelöst. Ebenso kann man sie schön für Kamerafahrten verwenden.<br /> <br /> Interessant ist jedoch, dass OpenGl auch die Möglichkeit besitzt, solche Kurven selber zu rendern. In reinem OpenGl kann man hier Evaluators verwenden. <br /> <br /> === Erster Versuch: Evaluator Kurve ===<br /> <br /> Als erstes wollen wir versuchen einen kubischen Bézier mit OpenGL Evaluators zu zeichnen. Definieren wir zuerst einmal 4 Kontrollpunkte:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> const<br /> ctrlpoints : Array[0..3] of Array[0..2] of TGlFloat =<br /> ((-4.0, 2.0, 0.0),(-2.0, 4.0, 0.0),(2.0, -4.0, 0.0),(4.0, 2.0, 0.0));<br /> &lt;/source&gt;<br /> <br /> Der nächste Schritt ist das Übergeben der Punkte an OpenGL:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glMap1f(GL_MAP1_VERTEX_3, 0, 1.0, 3, 4, @ctrlpoints[0,0]);<br /> glEnable(GL_MAP1_VERTEX_3);<br /> &lt;/source&gt;<br /> <br /> Kleine Erklärung von '''[[glMap1]]f''':<br /> <br /> Die 1 steht dafür, dass wir eine Linie beschreiben wollen. Eine 2, also '''[[glMap2]]f''' stünde für eine Fläche. Der erste Parameter beschreibt den Typ an Daten, den wir übergeben - in unserem Fall also dreidimensionale Vertexkoordinaten. Die nächsten 2 Parameter u&lt;sub&gt;1&lt;/sub&gt; und u&lt;sub&gt;2&lt;/sub&gt; beschreiben den Start- und Endwert unserer Kurve. Sie beschreiben sozusagen die Werte, die der Parameter t aus dem vorigen Kapitel haben muss, um eine komplette Kurve zu beschreiben. Der Parameter stride sagt aus, wie viele Floats vom Startfloat des einen Kontroll- bis zum Startfloat des nächsten Kontrollpunkts liegen. In unserem Fall also 3(Wegen Array[0..2] - hat 3 Elemente). Der vorletzte Parameter order sagt aus, wie viele Kontrollpunkte wir übergeben wollen. Zu guter Letzt noch ein Pointer auf die Kontrollpunkte, und wir haben unsere Schuldigkeit getan. <br /> <br /> Wir haben nun zwei Möglichkeiten unseren Evaluator zu zeichnen. Die erste:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> var<br /> i : Integer;<br /> ...<br /> glBegin(GL_LINE_STRIP);<br /> for i := 0 to 30 do<br /> glEvalCoord1f(i/30);<br /> glEnd;<br /> ...<br /> &lt;/source&gt;<br /> <br /> '''[[glEvalCoord]]1f''' erzeugt die Vertexdaten, die wir mittels [[glMap1]]f genauer definiert haben (diesmal also nur Vertexpositionen, keine Farben, keine Texturkoordinaten, etc.). Als Parameter werden Werte zwischen u&lt;sub&gt;1&lt;/sub&gt; und u&lt;sub&gt;2&lt;/sub&gt; eingesetzt.<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_openglcurve.gif]]<br /> <br /> Es gibt noch eine andere Methode, mit der man die Daten in einem Rutsch an OpenGL weitergeben kann:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glMapGrid1f(30, 0.0, 1.0);<br /> //...<br /> glEvalMesh1(GL_LINE, 0, 30);<br /> &lt;/source&gt;<br /> <br /> <br /> Mit [[glMapGrid]]1f stellen wir ein, in wieviele Segmente wir unsere Linie unterteilen wollen und übergeben gleichzeitig den Bereich in der Kurve u&lt;sub&gt;1&lt;/sub&gt; und u&lt;sub&gt;2&lt;/sub&gt;.<br /> <br /> [[glEvalMesh]]1 zeichnet nun unser gutes Stück als Linie. Gezeichnet werden alle Segmente von 0 bis 30.<br /> <br /> === Von Linien zu Flächen ===<br /> <br /> Die bisherigen Ergebnisse sind noch nicht wirklich überzeugend. Unser Ziel war es immerhin Oberflächen zu zeichnen und keine Linien. Aber weit entfernt sind wir nicht mehr. Beginnen wir damit, wieder unsere Kontrollpunkte zu definieren:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> var<br /> CtrlPoints2D : Array[0..3] of Array[0..3] of Array[0..2] of TGlFloat;<br /> &lt;/source&gt;<br /> <br /> Diesmal eine Variable? Ist er krank? Seit wann benutzt er Variablen? Nun ich kanns euch erklären: Ich habe mit mehreren unterschiedlichen Flächen herumgespielt und wollte nicht ständig dabei am Code herumbasteln, also habe ich mir fix eine Routine zum Laden der Punkte geschrieben:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure LoadCtrlPoints;<br /> var<br /> u, v : Integer;<br /> F : Text;<br /> begin<br /> AssignFile(F, 'surface.txt');<br /> Reset(F);<br /> FillChar(CtrlPoints2D[0,0,0], SizeOf(CtrlPoints2D), 0);<br /> for u := 0 to 3 do<br /> for v := 0 to 3 do<br /> ReadLn(F, CtrlPoints2D[u,v,0], CtrlPoints2D[u,v,1], CtrlPoints2D[u,v,2]);<br /> CloseFile(F)<br /> end;<br /> &lt;/source&gt;<br /> <br /> Ist die billigste Variante, ohne jeglichen Fehlerschutz, aber fürs herumspielen sollte das genügen. Sobald wir unsere Kontrollpunkte geladen haben, sollten wir sie an OpenGL übergeben: <br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> LoadCtrlPoints;<br /> glMap2f(GL_MAP2_VERTEX_3, 0.0, 1.0, 3, 4, 0.0, 1.0, 12, 4, @CtrlPoints2D[0,0,0]);<br /> glEnable(GL_MAP2_VERTEX_3);<br /> glEnable(GL_AUTO_NORMAL);<br /> glEnable(GL_NORMALIZE);<br /> glMapGrid2f(40, 0.0, 1.0, 40, 0.0, 1.0);<br /> &lt;/source&gt;<br /> <br /> Die [[glMap2]]f Funktionen haben jetzt ein paar neue Parameter erhalten. Dies sind an sich die gleichen Parameter wie bei den [[glMap1]]f Funktionen, nur dass sie nun doppelt vorhanden sind, für die v Richtung.<br /> <br /> Schlussendlich wollen wir noch unsere Oberflächen anzeigen:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glEvalMesh2(GL_FILL, 0, 40, 0, 40);<br /> &lt;/source&gt;<br /> <br /> Hat die Datei &quot;surface.txt&quot; nun folgenden Inhalt:<br /> <br /> -1.5 2.0 -1.5<br /> -0.5 -1.0 -1.5<br /> 0.5 -1.0 -1.5<br /> 1.5 -2.0 -1.5<br /> -1.5 2.0 -0.5<br /> -0.5 1.0 -0.5<br /> 0.5 -2.0 -0.5<br /> 1.5 0.0 -0.5<br /> -1.5 0.0 0.5<br /> -0.5 0.0 0.5<br /> 0.5 0.0 0.5<br /> 1.5 0.0 0.5<br /> -1.5 1.0 1.5<br /> -0.5 0.0 1.5<br /> 0.5 -1.0 1.5<br /> 3.0 -2.0 1.5<br /> <br /> <br /> dann könnte das enstehende Bild so aussehen:<br /> <br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_owncurve.gif]]<br /> <br /> === Texturen und anderes Feintuning ===<br /> <br /> Es ist schon bemerkenswert, wie leicht man Curved Surfaces in OpenGL zeichnen kann. Was fehlt, ist die Möglichkeit, die Flächen, die man erzeugt hat, auch noch zu texturieren. Jedem dürfte klar sein, was das für Vorteile hat.<br /> <br /> [[Bild:Tutorial_Abseits_eckiger_Welten_texturedcurve.gif]]<br /> <br /> Das schöne ist, dass man die Texturierung mit den gleichen Mitteln lösen kann, wie die Oberflächen selbst - mit Evaluators. Definieren wir uns also zuerst einmal ein paar Kontrollpunkte:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> const<br /> TexCoords : Array[0..1, 0..1, 0..1] of TGlFloat =<br /> (((0.0, 0.0),(0.0, 1.0)), ((1.0, 0.0),(1.0, 1.0)));<br /> &lt;/source&gt;<br /> <br /> und übergeben die Koordinaten an OpenGL:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> LoadCtrlPoints;<br /> glMap2f(GL_MAP2_VERTEX_3, 0.0, 1.0, 3, 4, 0.0, 1.0, 12, 4, @CtrlPoints2D[0,0,0]);<br /> <br /> LoadDevilTexture('flowers256.tga');<br /> glEnable(GL_TEXTURE_2D); <br /> <br /> glMap2f(GL_MAP2_TEXTURE_COORD_2, 0.0, 1.0, 2, 2, 0.0, 1.0, 4, 2, @TexCoords[0,0,0]);<br /> glEnable(GL_MAP2_TEXTURE_COORD_2);<br /> <br /> <br /> glEnable(GL_MAP2_VERTEX_3);<br /> glEnable(GL_AUTO_NORMAL);<br /> glEnable(GL_NORMALIZE);<br /> glMapGrid2f(40, 0.0, 1.0, 40, 0.0, 1.0);<br /> &lt;/source&gt;<br /> <br /> Wenn wir jetzt mittels glEvalMesh2(GL_FILL, 0, 40, 0, 40) die Szene rendern, bekommen wir das obige Bild. Simpel, nicht?<br /> <br /> Noch viel schöner wirds, wenn man feststellt, dass das gleiche nicht nur mit Texturkoordinaten funktioniert. Hier mal eine kleine Übersicht über die Parameter von glMapxf:<br /> <br /> {| border=&quot;1&quot;<br /> ! Konstante:<br /> ! Parameter:<br /> |-<br /> | GL_MAPx_VERTEX_3 || x,y,z Vertex-Koordinaten<br /> |-<br /> | GL_MAPx_VERTEX_4 || x,y,z,w Vertex-Koordinaten<br /> |-<br /> | GL_MAPx_INDEX || Farb-Index Werte<br /> |-<br /> | GL_MAPx_COLOR_4 || R,G,B,A Farbwerte<br /> |-<br /> | GL_MAPx_NORMAL || Normalen-Richtungen<br /> |-<br /> | GL_MAPx_TEXTURE_COORD_1 || s Textur-Koordinaten<br /> |-<br /> | GL_MAPx_TEXTURE_COORD_2 || s,t Textur-Koordinaten<br /> |-<br /> | GL_MAPx_TEXTURE_COORD_3 || s,t,r Textur-Koordinaten<br /> |-<br /> | GL_MAPx_TEXTURE_COORD_4 || s,t,r,q Textur-Koordinaten<br /> |}<br /> <br /> == NURBs ==<br /> <br /> Die OpenGL NURBs sind Teil der GL Utilities und damit bei jeder OpenGL-Implementation dabei. Im Redbook finden sich einige sehr schöne Beispiele, die die Verwendung von Nurbs zeigen. Eine Sache, die die NURBs interessant macht, ist die Möglichkeit sie trimmen zu können. Darunter fällt z.B. das Schneiden von Löchern mitten in die Fläche. Eine genaue Besprechung von NURBs würde den Rahmen dieses kleinen Tutorials sicher bei weitem sprengen, so dass ich beschließe hier meine kleine Einführung in das Thema Curved Surfaces zu beenden.<br /> <br /> [[Benutzer:Delphic|Delphic]]<br /> <br /> <br /> {{TUTORIAL_NAVIGATION| - | [[Tutorial_Renderpass]] }}<br /> <br /> [[Kategorie:Tutorial|Abseits eckiger Welten]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_Lektion_8&diff=23926 2009-07-23T15:08:49Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>= Das Wesen von Hell und Dunkel - Licht =<br /> <br /> == Licht an ==<br /> <br /> Hi,<br /> und wieder melde ich mich mit einem neuen Tutorial zurück. Heutiges Thema: Licht. Ohne Licht wäre die Umwelt dunkel und kein Pflänzchen könnte Zucker mittels Photosynthese erzeugen. Gäbe es kein Licht, so gäbe es die Welt nicht, wie wir sie kennen. Um in den eigenen OpenGL Programmen eine auch nur annähernd realistische Atmosphäre zu erzeugen ist Licht entsprechend unabdingbar. Man kann Szenen dadurch einen düsteren, geheimnisvollen oder auch einen farbenfrohen, fast kitschigen Stil verleihen.<br /> <br /> == Arten des Lichts ==<br /> <br /> In OpenGL gibt es unterschiedliche Arten des Lichts. Umgebungs-Licht ('''Ambient''') ist eine Art des Lichts, dessen Richtung nicht zu erkennen ist. Es entsteht durch mehrfache Reflexion an Wänden oder anderen Flächen. Entsprechend gut vertreten ist es in Räumen, aber auch in der freien Natur umgibt uns nicht zu wenig davon. An sich ist es das am schwierigsten zu berechnende, aber in vielen Szenen reicht es aus, eine Konstante vorzugeben - so macht es jedenfalls OpenGL.<br /> <br /> &quot;Diffuses&quot; Licht ('''Diffuse''') dagegen lässt die Richtung aus der es kommt erkennen. Je stärker eine Seite in das Licht gehalten wird, desto heller erscheint die Oberfläche. Je weiter man eine Fläche vom Licht abwendet, desto dunkler wird die Oberfläche. Die eintreffenden Lichtstrahlen werden in alle Richtungen verteilt, so dass die Oberfläche von allen Augenpositionen gleich hell erscheint.<br /> <br /> Glanz ('''Specular''') kommt aus einer bestimmten Richtung und tendiert dazu, in einer bestimmten Richtung besonders hell zu erscheinen. Plastik, gebürstetes oder nicht matt lackiertes Metall oder auch geschliffene Edelsteine haben einen hohen Glanzanteil, während Holz, Kohle und Wandfarbe so gar nicht glänzen wollen.<br /> <br /> == Materialeigenschaften ==<br /> <br /> Der vom Licht erzeugte Eindruck hängt aber nicht nur vom Licht selbst ab, sondern auch vom beleuchteten Material. Eine Kohleplatte wirkt im selben Licht anders, als eine polierte Edelstahloberfläche oder das Blech eines lackierten Autos. Deshalb gibt es in OpenGL die sog. Materialeigenschaften. Sie entsprechen denen des Lichts selbst, nur geben sie den Reflexionsgrad und nicht die Intensität wieder. {{Hinweis|Hier im Wiki findet ihr in der [[Materialsammlung]] eine Auswahl von Parameterwerten.}}<br /> <br /> Objekte können nun aber auch selbst Licht emittieren. Deshalb befindet sich unter den Materialeigenschaften zusätzlich noch ein Emissionswert. Ein Objekt mit Emission ist also auch bei kompletter Dunkelheit noch sichtbar, so z.B. die grüne Leuchtdiode an meinen Boxen, wenn ich die Rollläden geschlossen habe. Schade nur, dass OpenGL dieses emittierte Licht nicht auch auf andere Objekte überträgt :-(.<br /> <br /> == Normalen ==<br /> <br /> OpenGL berechnet die Farbe des Lichts, das auf ein Objekt trifft mit Hilfe der Richtung aus der das Licht kommt und der Ausrichtung der Oberfläche eines Vertex. Nun stellt sich die Frage: in welche Richtung zeigt denn die Oberfläche? Wir können bei der Übergabe der Vertexdaten einfach mit [[glNormal]]x die Normalen angeben. Die Länge des Normalenvektors sollte 1 sein. Bei einer Kugel entspricht die Normale übrigens immer der Richtung des Mittelpunktes zum betrachteten Vertex. Für kompliziertere Gegenstände gibt es weiter unten ein paar Tipps zum Berechnen der Normalen auf &quot;Nachbarschaftsbasis&quot;.<br /> <br /> == Erste Lichtstrahlen ==<br /> <br /> === Licht an ===<br /> <br /> [[Bild:Tutorial_lektion8_test.gif|center]]<br /> <br /> Es wird Zeit. Machen wir erste Gehversuche mit OpenGL Licht! Wir brauchen dazu nicht viel zu tun. Mit glEnable(GL_LIGHTING) schalten wir die Lichtberechnung scharf und müssen dann eine Lichtquelle aktivieren. Das geht mit glEnable(GL_LIGHTx) (Zur Information: OpenGL Implementationen müssen 8 Lichter unterstützen. Es gibt aber Implementationen, die hier mehr zu bieten haben. Um Zugriff auf alle vorhandenen Lichter zu erhalten, genügt es zu GL_LIGHT0 einen entsprechenden Wert zu addieren. GL_LIGHT0+8 wäre dann z.B. das 9. Licht).<br /> <br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glEnable(GL_LIGHTING);<br /> glEnable(GL_LIGHT0);<br /> glEnable(GL_COLOR_MATERIAL);<br /> &lt;/source&gt;<br /> <br /> === Sonnenbrand erzeugen ===<br /> <br /> Der nächste Schritt besteht darin, die Eigenschaften der Lichtquelle(n) an OpenGL weiterzureichen. Dies läuft immer mit der Funktion '''[[glLight]]x'''. Sie nimmt 3 Parameter: '''light''': Die Lichtquelle die gerade eingestellt wird. '''pname''': Die Eigenschaft, die wir manipulieren möchten. '''params''': Der neue Wert der Eigenschaft.<br /> <br /> Mit '''pname''' dürfen wir aus einer ganzen Sammlung von Eigenschaften schöpfen:<br /> <br /> {| border=&quot;1&quot; align=&quot;center&quot;<br /> ! Eigenschaft<br /> ! Standard Wert<br /> ! Bedeutung<br /> |-<br /> | GL_AMBIENT || 0.0, 0.0, 0.0, 1.0 || Ambienter RGBA Anteil des Lichtes<br /> |-<br /> | GL_DIFFUSE || 1.0, 1.0, 1.0, 1.0 || Diffuser RGBA Anteil des Lichtes<br /> |-<br /> | GL_SPECULAR || 1.0, 1.0, 1.0, 1.0 || Glanz RGBA Anteil des Lichtes<br /> |-<br /> | GL_POSITION || 0.0, 0.0, 1.0, 0.0 || Koordinaten des Lichtes<br /> |-<br /> | GL_SPOT_DIRECTION || 0.0, 0.0, -1.0 || Richtung des Spotlights<br /> |-<br /> | GL_SPOT_EXPONENT || 0.0 || Spotlight-Exponent<br /> |-<br /> | GL_SPOT_CUTOFF || 180.0 || Spotlight Sperrwinkel<br /> |-<br /> | GL_xxx_ATTENUATION || ... || Abschwächung des Lichtes mit der Entfernung<br /> |}<br /> <br /> === Materialeigenschaften übergeben ===<br /> <br /> Das gleiche Spielchen müssen wir mit den Materialeigenschaften treiben. Diesmal ist die Funktion '''[[glMaterial]]x''' der Dreh und Angelpunkt. Die Parameterfolge ist die gleiche wie bei '''[[glLight]]x'''.<br /> <br /> {| border=&quot;1&quot; align=&quot;center&quot;<br /> ! Eigenschaft<br /> ! Standard Wert<br /> ! Bedeutung<br /> |-<br /> | GL_AMBIENT || 0.2, 0.2, 0.2, 1.0 || RGBA Reflexionsgrad von ambientem Licht<br /> |-<br /> | GL_DIFFUSE || 0.8, 0.8, 0.8, 1.0 || RGBA Reflexionsgrad von diffusem Licht<br /> |-<br /> | GL_SPECULAR || 0.0, 0.0, 0.0, 1.0 || RGBA Glanzreflexionsgrad des Lichtes<br /> |-<br /> | GL_SHININESS || 0.0 || Glanz-Exponent<br /> |-<br /> | GL_EMISSION || 0.0, 0.0, 0.0, 1.0 || RGBA Emission des Materials<br /> |-<br /> | GL_COLOR_INDEXES || 0, 1, 1 || Ambient, diffuse, specular Farbindices<br /> |}<br /> <br /> === Beispiellicht ===<br /> <br /> Das Beispiel mit den Kugeln wurde mit folgendem Code erzeugt:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> procedure TStationarySphereState.RenderState;<br /> const<br /> mat_specular : Array[0..3] of GlFloat = (1.0, 1.0, 1.0, 1.0);<br /> mat_shininess : Array[0..0] of GlFloat = (50.0);<br /> mat_ambient : Array[0..3] of GlFloat = (0.4, 0.4, 0.4, 1.0);<br /> mat_diffuse : Array[0..3] of GlFloat = (0.4, 0.8, 0.4, 1.0);<br /> <br /> light_position : Array[0..3] of GlFloat = (10.0, 10.0, 0.0, 1.0);<br /> light_ambient : Array[0..3] of GlFloat = (0.8, 0.8, 0.8, 1.0);<br /> light_diffuse : Array[0..3] of GlFloat = (0.8, 0.8, 0.8, 1.0);<br /> <br /> begin<br /> glMaterialfv(GL_FRONT, GL_SPECULAR, @mat_specular[0]);<br /> glMaterialfv(GL_FRONT, GL_SHININESS, @mat_shininess[0]);<br /> glMaterialfv(GL_FRONT, GL_AMBIENT, @mat_ambient[0]);<br /> glMaterialfv(GL_FRONT, GL_DIFFUSE, @mat_diffuse[0]);<br /> <br /> glLightfv(GL_LIGHT0, GL_AMBIENT, @light_ambient[0]);<br /> glLightfv(GL_LIGHT0, GL_DIFFUSE, @light_diffuse[0]);<br /> glLightfv(GL_LIGHT0, GL_POSITION, @light_position[0]);<br /> <br /> glEnable(GL_COLOR_MATERIAL);<br /> glEnable(GL_LIGHTING);<br /> glEnable(GL_LIGHT0);<br /> ...Szene Rendern...<br /> end;<br /> &lt;/source&gt;<br /> <br /> == Etwas schwächer bitte ==<br /> <br /> Viele Lichtquellen werden mit der Entfernung schwächer. Bei unserer Sonne tritt dieser Effekt so gut wie nicht auf, bei kleinen Funzeln dagegen ist recht bald die maximale Leuchtweite erreicht. Diesen Effekt können wir auch mit OpenGL nachahmen.<br /> <br /> [[Bild:Tutorial_lektion8_attenuation.gif|center]]<br /> <br /> Auf diesem Bild ist schön zu erkennen, dass die Kugeln rechts oben heller sind als die links unten, welche weiter von der Lichtquelle entfernt sind (wer nichts sieht, spiele doch mal bitte mit dem [[Farbraum#Grundlegende_Bildschirmkalibrierung|Kontrast und der Helligkeit]] des Monitors - ich kann nicht versprechen, dass der Effekt auf jedem Monitor so schön wie auf meinem herauskommt). Wie wird nun dieser Effekt erzeugt?<br /> <br /> OpenGL kennt einen sog. Attenuation Factor:<br /> <br /> Attenuation Factor = 1 / (k&lt;sub&gt;c&lt;/sub&gt; + k&lt;sub&gt;l&lt;/sub&gt;*d + k&lt;sub&gt;q&lt;/sub&gt;*d*d)<br /> <br /> * d = Entfernung zwischen dem berechneten Vertex und der Lichtquelle<br /> * k&lt;sub&gt;c&lt;/sub&gt; = GL_CONSTANT_ATTENUATION<br /> * k&lt;sub&gt;l&lt;/sub&gt; = GL_LINEAR_ATTENUATION<br /> * k&lt;sub&gt;q&lt;/sub&gt; = GL_QUADRATIC_ATTENUATION<br /> <br /> Dieser wird Faktor bei der Lichtberechnung einfach mit den Lichtstärken multipliziert, so dass das Licht stärker oder schwächer wird. Übergeben werden die Werte wieder mittels '''[[glLight]]x''':<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glLightf(GL_LIGHT0, GL_CONSTANT_ATTENUATION, 1.0);<br /> glLightf(GL_LIGHT0, GL_LINEAR_ATTENUATION, 0.001);<br /> glLightf(GL_LIGHT0, GL_QUADRATIC_ATTENUATION, 0.004);<br /> &lt;/source&gt;<br /> <br /> == Das Positionsproblem ==<br /> <br /> Lichter sind unterschiedlich - Manche sind fest an den Kopf des Betrachters gekoppelt, andere irgendwo in der Szene platziert und wieder andere sind unendlich weit entfernt und ihr Licht trifft parallel auf die Gegenstände. All dies will simuliert werden. OpenGL hält es parat. Uns kommt auch noch zugute, dass OpenGL die Übergabe der Licht Position genauso behandelt wie die eines Vertex und entsprechend durch die Modelview Matrix jagt.<br /> <br /> === Unendlich weit entfernte Lichter ===<br /> <br /> Das Universum, die Milchstraße, der äußere Ring, unser Sonnensystem, die Sonne und unsere Erde. Das Licht, das unsere Sonne ausstrahlt und bei uns auf der Erde ankommt, trifft uns in nahezu parallelen Lichtstrahlen. Damit verhält sich die Sonne wie eine unendlich entfernte Lichtquelle. Wenn wir eine solche Lichtquelle angeben wollen, ist also nicht ihre Position interessant (wobei das auch ginge), sondern allein die Richtung aus der das Licht kommt. Wie? Wir setzen die w-Koordinate(=die letzte Koordinate) der Position auf 0. Unsere unendlich weit entfernte Lichtquelle ist komplett. Sinnigerweise ist dann im übrigens auch Attenuation abgeschaltet.<br /> <br /> === Stationäre Lichtquellen ===<br /> <br /> Lichtquellen, die an einer bestimmten Stelle in der Szene stehen, müssen mit der Kamerabewegung mitgeschoben werden. Entsprechend wird das Licht angegeben werden, bevor die Modelviewmatrix durch Objekte verschoben wird, aber nachdem die Kamera initialisiert wurde.<br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glLoadIdentity;<br /> //..glRotatef, glTransaltef.. für die Kamera<br /> glLightfv(GL_LIGHT0, GL_POSITION, @position[0]);<br /> glPushMatrix;<br /> //..glRotatef, glTransaltef.. für die Objekte<br /> DrawObjekts;<br /> glPopMatrix;<br /> &lt;/source&gt;<br /> <br /> === Relatives Licht ===<br /> <br /> Wollen wir stattdessen unsere Lichtquelle relativ zu einem bestimmten Objekt bewegen, so müssen wir ein wenig anders vorgehen: Erst die Modelviewmatrix so bearbeiten, dass wir das Objekt zeichnen könnten, vor dem Zeichen selbst jedoch die Matrixfunktion für das Licht ausführen und die Lichtposition übergeben:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> //..glRotatef, glTransaltef, glMultMatrix, etc...<br /> glPushMatrix;<br /> glRotatef(Drehung, 0.0, 1.0, 0.0);<br /> glLightfv(GL_LIGHT0, GL_POSITION, @position[0]);<br /> glPopMatrix;<br /> DrawObject;<br /> &lt;/source&gt;<br /> <br /> === Lichtquellen, die an der Kamera kleben ===<br /> <br /> Wenn eine Lichtquelle immer relativ zum Betrachter sein soll(wenn also das Licht z. B. feste am Kopf montiert ist, wie bei einem Minenarbeiter), so langt es die Position des Lichts zu definieren, bevor die Modelviewmatrix mit der Kameraposition und Drehung bearbeitet wurde:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glLoadIdentity;<br /> glLightfv(GL_LIGHT0, GL_POSITION, @position[0]);<br /> &lt;/source&gt;<br /> <br /> == Spot an! ==<br /> <br /> Wer kennt sie nicht, die Spotlights? Im Fernsehen und Theater oft gebraucht, aber auch im realen Leben, z.B. bei Taschenlampen, Suchscheinwerfern (etwa noch keinen in der Hand gehabt? Ich schon :-) ), etc. oft zu sehen. Leider benötigt man nicht selten eine ganze Schar von ihnen, wozu sich die OpenGL Lichter nur schlecht eignen - aus der Patsche hilft da oft [[Blending]] oder andere Techniken. Wenn man mit entsprechenden Projektions-Techniken noch keine Erfahrungen hat, müssen die OpenGL-Lichter dann aber doch wieder herhalten.<br /> <br /> === Parameter setzen ===<br /> <br /> [[Bild:Tutorial_lektion8_spotlight.gif|center]]<br /> <br /> Schauen wir uns die Lichtparameter für Spotlights an: '''GL_SPOT_DIRECTION''' gibt die Richtung an, in die das Spotlicht zeigt. Diese lässt sich wieder mit Hilfe geschickter Platzierung im Code durch die Modelviewmatrix jagen um den gewünschten Effekt zu erzielen - wie immer eben. '''GL_SPOT_CUTOFF''' gibt den Winkel an, der zwischen Richtung und max. Auswurf besteht. Zuletzt gibt es noch den '''GL_SPOT_EXPONENT''', der beschreibt, wie stark die Lichtstärke nach außen hin abnimmt.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> const<br /> light_position : Array[0..3] of GlFloat = (0.0, 10.0, 0.0, 1.0);<br /> light0_ambient : Array[0..3] of GlFloat = (0.8, 0.0, 0.0, 1.0);<br /> light0_diffuse : Array[0..3] of GlFloat = (0.8, 0.0, 0.0, 1.0);<br /> var<br /> LightDirection : Array[0..2] of GlFloat;<br /> begin<br /> LightDirection[0] := Sin(Position)/2;<br /> LightDirection[1] := -1.0;<br /> LightDirection[2] := 0.0;<br /> glLightfv(GL_LIGHT0, GL_SPOT_DIRECTION, @LightDirection[0]);<br /> <br /> glLightf(GL_LIGHT0, GL_SPOT_CUTOFF, 10.0);<br /> glLightf(GL_LIGHT0, GL_SPOT_EXPONENT, 50.0);<br /> <br /> glLightfv(GL_LIGHT0, GL_AMBIENT, @light0_ambient[0]);<br /> glLightfv(GL_LIGHT0, GL_DIFFUSE, @light0_diffuse[0]);<br /> glLightfv(GL_LIGHT0, GL_POSITION, @light_position[0]);<br /> glEnable(GL_LIGHT0);<br /> glEnable(GL_LIGHTING);<br /> //...<br /> end;<br /> &lt;/source&gt;<br /> <br /> Zur besseren Illustration ein Bild<br /> <br /> [[Bild:Tutorial_lektion8_spots_highres.gif|center]]<br /> <br /> == glLightModel? ==<br /> <br /> Bislang haben wir einen Befehl völlig ausser Acht gelassen: '''[[glLightModel]]x'''. Er nimmt zwei Parameter: '''pname''' und '''param''':<br /> <br /> {| border=&quot;1&quot; align=&quot;center&quot;<br /> ! Eigenschaft<br /> ! Standard Wert<br /> ! Bedeutung<br /> |-<br /> | GL_LIGHT_MODEL_AMBIENT<br /> | 0.2, 0.2, 0.2, 1.0<br /> | Abientes RGBA Licht der gesamten Szene<br /> |-<br /> | GL_LIGHT_MODEL_LOCAL_VIEWER<br /> | 0.0 oder GL_FALSE<br /> |Lokaler oder unendlicher Viewport. Wirkt bei Specular Reflexionen:<br /> ;GL_FALSE: Die Richtung von Betrachter zu Vertex wird nur 1 mal berechnet und bleibt damit für alle Vertices konstant.<br /> ;GL_TRUE: Die Richtung Betrachter zu Vertex wird für jedes Vertex neu berechnet, was in einem realistischeren Anblick endet.<br /> |-<br /> | GL_LIGHT_MODEL_TWO_SIDE<br /> | 0.0 oder GL_FALSE<br /> | Einseitiges oder doppelseitiges Lighting<br /> |}<br /> <br /> == Das Vertexproblem ==<br /> <br /> Die Benutzung von Licht muss bislang auf euch sehr einfach gewirkt haben. Aber der eine oder andere wird es vielleicht schon herausgelesen haben: OpenGL Licht wird per Vertex und nicht per Pixel berechnet. Das Problem dabei ist, dass sich mit der Auflösung des Objekts das Aussehen des Lichts stark ändern kann. Bei diffusem und ambientem Licht spielt das kaum eine Rolle. Specular und Spotlights reagieren empfindlich. Die schönen Rundungen, die diese Lichtarten häufig ausbilden, können verschandelt werden. Die Ergebnisse sind nicht mehr wirklich rund, vielmehr eckig und kantig. Ihr glaubt mir nicht? Dann schaut nicht zu genau hin:<br /> <br /> [[Bild:Tutorial_lektion8_spots_lowres.gif|center]]<br /> <br /> Und was lernen wir draus? Schönes Licht braucht viele Vertices.<br /> <br /> == Normalen die 2. ==<br /> <br /> === Länge = 1? ===<br /> <br /> Kommen wir also nun wie versprochen noch einmal zu den Normalen zurück. Normalen, die mit [[glNormal|glNormalx]] angegeben werden, werden, abgesehen von Verschiebungen, wie Vertices mit der Modelview Matrix multipliziert. Normalen sollten für korrekte Lichtberechnung normiert sein, dass heißt die Länge 1 haben (ist sie länger, so erscheint das Objekt heller, ist sie kürzer, so wird das Objekt dunkler). Ist mit der Multiplikation mit der Modelviewmatrix auch eine Skalierung verbunden, so haben wir ein Problem, denn die Länge ist nicht mehr 1. Um das zu beheben, kann vermittels '''[[glEnable]](GL_NORMALIZE)''' OpenGL angewiesen werden, die Normalen selbst auf Länge eins zu skalieren. Aber Achtung: Das kostet Rechenleistung. Allerdings kostet selber berechnen vermutlich noch mehr.<br /> <br /> === Einfache Normalen ===<br /> <br /> Manchmal ist die Berechnung von Normalen ganz einfach. So bei Kugeln. Die Richtung die der Mittelpunkt zu irgendeinem Vertex auf der Oberfläche beschreibt, ist gleich der Richtung der Normalen - sie muss nur noch normiert werden. Bei Flächen auf den Achsen muss unsereins auch nicht groß nachdenken, wie denn die passende Normale auszusehen hat. Aber wie ist es, wenn unser betrachteter Körper keine so einfache Oberfläche hat? Was dann?<br /> <br /> === Normalenberechnung per Dreieck ===<br /> <br /> Will man anhand von Dreiecksdaten Normalen erzeugen, so muss man mal wieder zur Mathematik rüberschauen - die haben das ideale Werkzeug dafür: Das [[Vektorprodukt|Vektor-Kreuzprodukt]]. Um die Normale der Fläche beschrieben durch die 3 Ecken V&lt;sub&gt;1&lt;/sub&gt;, V&lt;sub&gt;2&lt;/sub&gt;, V&lt;sub&gt;3&lt;/sub&gt; zu bekommen, braucht man nur zu rechnen:<br /> <br /> N = (V&lt;sub&gt;1&lt;/sub&gt; - V&lt;sub&gt;2&lt;/sub&gt;)x(V&lt;sub&gt;2&lt;/sub&gt; - V&lt;sub&gt;3&lt;/sub&gt;)<br /> <br /> Wenn wir das für jedes Polygon durchziehen, dann können wir für jeweils 3 Vertices die Normale angeben. Das schaut ein bisschen eckig aus, bringt uns unserem Ziel aber gewaltig näher. Erinnert irgendwie an die ersten Spiele, die mit Licht arbeiteten... Flatshading war schon was schönes, aber OpenGL kann mehr, wie wir bereits an den Kugeln gesehen haben.<br /> <br /> [[Bild:Tutorial_lektion8_normalen_flat.gif|center]]<br /> <br /> '''Und nicht vergessen:''' Die Normalen sollten noch auf die Länge 1 gebracht werden, siehe [[Normale]].<br /> <br /> === Normalen glätten ===<br /> <br /> [[Bild:Tutorial_lektion8_normalen_smooth.gif|center]]<br /> <br /> Um die Polygone nun ein wenig unsichtbarer zu machen, gibt es ein einfaches Hilfsmittel: Man nehme die direkt anliegenden Flächennormalen um ein Vertex, bilde den Durchschnitt und voilà: Unser Objekt schaut schon runder aus. An einigen Stellen sollte man damit aber vorsichtig walten: Geht es einmal wirklich scharf um eine spitze Kante, so schaut diese Abrundung vermutlich etwas seltsam und abnormal aus. Also: Nicht einfach drauflos abrunden. Da bei komplexeren Objekten jeder vermutlich sowieso einen 3D Modeller verwendet, bei dem man das etwas feinfühlig kontrollieren kann, sollte das kein größeres Problem sein - jeder der seinen eigenen Modeller schreibt, muss sich natürlich etwas einfallen lassen - nützlich erweist sich hier das [[Standard_Skalarprodukt|Skalarprodukt]], da man damit den Winkel zwischen zwei Normalen bestimmen kann. Ist der Winkel zu groß, kann es sich nicht um eine Rundung handeln und wir haben es mit einer Kante zu tun - zumindest solange unsere Polygondaten halbwegs fein aufgelöst sind.<br /> <br /> == Das etwas andere Licht ==<br /> <br /> [[Bild:Tutorial_lektion8_RoteRinge.jpg|center]]<br /> <br /> Mit OpenGL's Standardmethode einen Beleuchtungseffekt zu erzielen, ist natürlich nicht der Weisheit letzter Schluss. Ein anderer Trick drängt sich bei entsprechendem Wissen über die Möglichkeiten geradezu auf: Environment Mapping, oder im folgendem speziell Sphere Mapping. Den entstehenden Effekt kann man mit einer perfekten Spiegelung vergleichen. Das einzige was wir tun müssen, ist OpenGL anzuweisen, die Texturkoordinaten selbst zu berechnen:<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);<br /> glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);<br /> glEnable(GL_TEXTURE_GEN_S);<br /> glEnable(GL_TEXTURE_GEN_T);<br /> &lt;/source&gt;<br /> <br /> Das wars schon, wir benötigen nur noch eine Sphere Map:<br /> <br /> [[Bild:Tutorial_lektion8_lightmap.jpg|center]]<br /> <br /> Wenn man das ganze nun noch mit [[Multitexturing]] verknüpft, so kann man eine Texturlage für die normale Textur verwenden und die 2. für das Licht. Eine rote Spheremap erzeugt aber rotes Licht, gell... Happy Coding ;-)<br /> <br /> == Licht aus ==<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;<br /> glDisable(GL_LIGHTING)<br /> &lt;/source&gt;<br /> <br /> Und wieder ist eines meiner Tutorials am Ende. Wenn ich mich nicht irre ists die Nummer 11. Wer gibt mir den verdienten Schnaps aus? Na? Keine Freiwilligen? Schade :-( . In jedem Fall hast Du es jetzt erst einmal hinter Dir und kannst Dich ganz entspannt zurücklehnen - oder, was mir besser gefallen würde: Ein paar OpenGL Programme mit Lichtunterstützung schreiben und uns das Ergebnis als IOTW oder als solches einsenden. Ersatzweise tuts auch etwas freundliches Feedback - das lasst ihr nämlich allesamt immer sehr missen, was das Team zurecht schade findet. Also lasst uns nicht hängen, sondern gebt von euch, was euch an den Tutorials gefällt und was nicht.<br /> <br /> und jetzt:<br /> <br /> ...have a lot of fun!<br /> <br /> '''[[Benutzer:Delphic|Delphic]]<br /> &amp; Co-Autor [[Benutzer:Traude|Traude]]'''<br /> <br /> {{TUTORIAL_NAVIGATION | [[Tutorial Lektion 7]] | [[Tutorial 2D]] }}</div>

Delphic https://wiki.delphigl.com/index.php?title=Team&diff=23925 2009-07-23T15:07:59Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>= Vorwort =<br /> <br /> Auf dieser Seite befindet sich eine Auflistung der Personen, die momentan aktiv daran arbeiten, dass DGL Euch wie gewohnt im Netz mit Informationen versorgt. Bitte beachtet, dass die meisten der Personen nur einen begrenzten Vorrat an Zeit haben. Überlegt daher bitte sorgsam, an wen Ihr Euch wendet.<br /> <br /> Im unteren Teil dieser Seite sind die verschiedenen Bereiche von DGL und deren Betreuer aufgelistet. Bitte wendet auch an den passenden Ansprechpartner.<br /> <br /> Diese Seite ersetzt nicht das '''[http://www.delphigl.com/launcher.php?em=impressum IMPRESSUM]'''.<br /> <br /> = Das Team im Ganzen =<br /> In diesen Abschnitt ist aufgelistet '''wer''' bei [[DelphiGL]] Verantwortung für einen Teil übernommen hat, und '''was''' genau er macht.<br /> == Moderatoren ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;80%&quot;<br /> !width=&quot;20%&quot;|Forumsname<br /> !width=&quot;30%&quot;|Email<br /> !width=&quot;50%&quot;|Aufgabenbereich<br /> |-<br /> |[[Benutzer:Phobeus|Phobeus]] <br /> |{{eMail|Phobeus|delphigl.com}}<br /> |<br /> *Technische Pflege des Wikis (Wartung/Updates)<br /> *Betreuung der Hardware<br /> *Freischalten von Usern für das Forum<br /> *Freischalten von Usern für das Wiki<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> *&quot;der Chef&quot;<br /> |-<br /> |[[Benutzer:Flash|Flash]] <br /> |{{eMail|Flash|delphigl.com}}<br /> |<br /> *Inhaltliche Pflege des Wikis<br /> *DGL-Poll pflegen<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle im Forum<br /> |-<br /> |[[Benutzer:Delphic|Delphic]] <br /> |{{eMail|delphic|delphigl.com}}<br /> |<br /> *Freischalten von Usern für das Forum<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> |-<br /> |[[Benutzer:Lossy eX|Lossy eX]] <br /> |{{eMail|Lossy|delphigl.com}}<br /> |<br /> *dglOpenGL.pas<br /> *Freischalten von Usern für das Forum<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> |-<br /> |[[Benutzer:Flo|Flo]]<br /> |{{eMail|Flo|DelphiGL.com}}<br /> |<br /> *Freischalten von Usern für das Wiki<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> |-<br /> |[[Benutzer:I0n0s|i0n0s]] <br /> |{{eMail|i0n0s|DelphiGL.com}}<br /> |<br /> *DGLSDK<br /> *Freischalten von Usern für das Forum<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> |-<br /> |[[Benutzer:Sascha Willems|Sascha Willems]] <br /> |{{eMail|webmaster|delphigl.de}}<br /> |<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> |-<br /> |[[Benutzer:Magellan|Magellan]] <br /> |{{eMail|Magellan|delphigl.com}}<br /> |<br /> *News eintragen<br /> *allgemeine inhaltliche Kontrolle<br /> |-<br /> |[[Benutzer:La Boda|La Boda]] <br /> |{{eMail| -pdl-|web.de}}<br /> |<br /> *allgemeine inhaltliche Kontrolle<br /> *News eintragen<br /> |-<br /> |}<br /> &lt;/div&gt;<br /> <br /> = Gruppen =<br /> In diesem Teil findet ihr detailierte Informationen, wer für welchen Bereich zuständig ist.<br /> == DGLSDK ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;80%&quot;<br /> !width=&quot;20%&quot;|Forumsname<br /> !width=&quot;30%&quot;|Email<br /> !width=&quot;50%&quot;|Aufgabenbereich<br /> |-<br /> |[[Benutzer:I0n0s|i0n0s]] <br /> |{{eMail|i0n0s|DelphiGL.com}}<br /> |<br /> |-<br /> |}<br /> &lt;/div&gt;<br /> <br /> == DGLOpenGL.pas ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;80%&quot;<br /> !width=&quot;20%&quot;|Forumsname<br /> !width=&quot;30%&quot;|Email<br /> !width=&quot;50%&quot;|Aufgabenbereich<br /> |-<br /> |[[Benutzer:Lossy eX|Lossy eX]] <br /> |{{eMail|Lossy|delphigl.com}}<br /> |<br /> *Weiterentwicklung, Debugging<br /> |-<br /> |}<br /> &lt;/div&gt;<br /> <br /> == Webseite ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;80%&quot;<br /> !width=&quot;20%&quot;|Forumsname<br /> !width=&quot;30%&quot;|Email<br /> !width=&quot;50%&quot;|Aufgabenbereich<br /> |-<br /> |[[Benutzer:Phobeus|Phobeus]] <br /> |{{eMail|Phobeus|delphigl.com}}<br /> |<br /> *Technische Pflege des Seite (Wartung/Updates)<br /> *Coding (Integrieren von Neuerungen)<br /> |-<br /> |[[Benutzer:Flash|Flash]] <br /> |{{eMail|Flash|delphigl.com}}<br /> |<br /> *DGL-Poll pflegen<br /> |-<br /> |Alle Anderen <br /> |(siehe oben)<br /> |<br /> *News<br /> *Sorgen für angemessene Umgangsformen<br /> |-<br /> |}<br /> &lt;/div&gt;<br /> <br /> == Wiki ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;80%&quot;<br /> !width=&quot;20%&quot;|Forumsname<br /> !width=&quot;30%&quot;|Email<br /> !width=&quot;50%&quot;|Aufgabenbereich<br /> |-<br /> |[[Benutzer:Flash|Flash]] <br /> |{{eMail|Flash|delphigl.com}}<br /> |<br /> *Inhaltliche Pflege des Wikis<br /> *Koordinierung<br /> |-<br /> |[[Benutzer:Phobeus|Phobeus]] <br /> |{{eMail|Phobeus|delphigl.com}}<br /> |<br /> *Technische Pflege des Wikis (Wartung/Updates)<br /> *Betreuung der Hardware<br /> |-<br /> |[[Benutzer:La Boda|La Boda]]<br /> |{{eMail| -pdl-|web.de}}<br /> |<br /> *Inhaltliche Pflege des Wikis<br /> |-<br /> |}</div>

Delphic https://wiki.delphigl.com/index.php?title=DelphiGL&diff=23924 2009-07-23T15:07:23Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>{|<br /> |Dieser Artikel beschäftigt sich mit [http://DelphiGL.com DelphiGL.com].&lt;br&gt; <br /> DelphiGL ist die Website welche dieses Wiki betreibt und das angeschlossene Forum ist der feste Hafen für deutschsprachige OpenGL-Programmierer im sturmumtosten GrafikAPI-Ozean.<br /> <br /> Informationen zum Team findet ihr im Artikel [[Team]].<br /> |&lt;div align=&quot;right&quot;&gt;[http://delphiGL.com http://delphigl.com/gfx/banner/banner256x64.gif]&lt;/div&gt;<br /> &lt;small&gt;Falls Ihr auf DelphiGL.com oder das DGL-Wiki verlinken wollt, findet ihr die nötigen Banner '''[[DelphiGL_Banner|hier]]'''.&lt;/small&gt;<br /> |-<br /> |}<br /> <br /> <br /> ==Mitgliederentwicklung==<br /> [[Bild:DGL_Mitgliederzahlen.jpg|center|framed|<br /> Monatliches Wachstum der DGL Community (Angemeldete User im Forum):&lt;br&gt;<br /> - insgesamt: 19,57 Mitglieder.&lt;br&gt;<br /> - letzten 12 Monate: 18 Mitglieder.&lt;br&gt;<br /> - letzten 6 Monate: 15,66 Mitglieder.]]<br /> <br /> <br /> Für Liebhaber von Statistiken: <br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}}<br /> |+Halbjährliche Mitgliederentwicklung<br /> !Zeitraum<br /> !durchschnittlicher Zuwachs<br /> |-<br /> |01.06.02 - 01.11.02<br /> |13<br /> |-<br /> |01.12.02 - 01.05.03<br /> |13.5<br /> |-<br /> |01.06.03 - 01.11.03<br /> |17.66<br /> |-<br /> |01.12.03 - 01.05.04<br /> |16<br /> |-<br /> |01.06.04 - 01.11.04<br /> |18<br /> |-<br /> |01.12.04 - 01.05.05<br /> |19.5<br /> |-<br /> |01.06.05 - 01.11.05<br /> |19.83<br /> |-<br /> |01.12.05 - 01.05.06<br /> |31<br /> |-<br /> |01.06.05 - 01.11.06<br /> |21.67<br /> |-<br /> |01.12.06 - 01.05.07<br /> |26.83<br /> |-<br /> |01.06.07 - 01.11.07<br /> |21.16<br /> |-<br /> |01.12.07 - 01.05.08<br /> |21.33<br /> |-<br /> |01.06.08 - 01.11.08<br /> |15.83<br /> |-<br /> |}<br /> &lt;/div&gt;<br /> <br /> ==Geschichte von DelphiGL.com==<br /> ===Die frühsten Anfänge===<br /> Blickt man insbesondere vor das Jahr 2000 war die Grafikprogrammierung unter Delphi eine ziemlich frustrierende Angelegenheit. Nur sehr wenige Quellen waren überhaupt verfügbar, ganz zu schweigen von notwendigen Headern. Ein erste Etappe dieser Durststrecke war vermutlich das Erscheinen von DelphiX, dass sich binnen kurzer Zeit einer sehr großen Popularität erfreute. Der gemeinsame Treffpunkt hierfür war das alte Forum auf www.neobrothers.de. Prinzipiell machte die Community bis zu diesem Zeitpunkt nichts anderes als langsam zu wachsen und alle Varianten der Grafikprogrammierung durchzugehen. Vermutlich gab es damals kaum jemanden der nicht DelphiX, WdirectX oder diverse andere Header durchprobierte.<br /> <br /> Anfang 2002 kam es dann im Neobrothers-Forum zu einer Umfrage, ob man nicht ein Unterforum für OpenGL einrichten sollte. Zu diesem Zeitpunkt war mir (Phobeus) der Begriff OpenGL noch kaum ein Begriff. Da ich zu diesem Zeitpunkt jedoch zunehmend unzufriedener mit Direct3D wurde (Ständige Wechsel der API, zuviel Code für zu wenig Ergebnis etc.) riskierte ich einen Blick auf OpenGL und begann, mich damit auseinander zu setzen. Die Seite erster Wahl war damals für den OpenGL-Programmierer definitiv NeHe und erlaubte es mir, mich relativ schnell in OpenGL einzuarbeiten. Das Ergebnis beeindruckte mich: Wenige Wochen und man konnte fast das gleiche machen wie mit Direct3D, allerdings oftmals mit erheblich weniger Code und alleine die Tatsache, dass man mit ein paar glVertex-Aufrufen schnell Figuren bilden konnte, beeindruckte mich sehr.<br /> <br /> Zeitgleich nahm die Umfrage im Neobrothers-Forum ein Ende und mit nur wenigen Stimmen Vorsprung siegte die Direct3D-Fraktion und es wurde abgelehnt ein entsprechendes Unterforum einzurichten. Ich selbst war zu diesem Zeitpunkt über das Ergebnis ziemlich enttäuscht. Ebenso ein weiteres Mitglied aus dem Forum namens Sebo, den man streng genommen als geistigen Vater von DGL nennen muss.<br /> <br /> Ich selbst besaß damals ausreichend Webspace und unterhielt dort eine kleine Seite für einige Projekte meinerseits. Er fragte mich, ob man nicht dort dann ein Unterforum einrichten könnte. Ich selbst war ziemlich skeptisch darüber, da ich nicht glaubte, dass ein kleines Unterforum in meinem „Gästebuch“ wirklich Interessierte anlocken könnte. Ich wollte Nägel mit Köpfen machen und es wurde mir hier erstmals bewußt, dass ich unlängst OpenGL als meine künftige API gewählt habe und definitiv nicht mehr zu Direct3D zurück wollte. Nach einer kurzen Sammlung von Ideen, Plänen und dem Entschluss auch Tutorials anbieten zu wollen, ging am 1. April 2002 die Webseite http://dgl.thechaoscompany.net/ (nicht mehr im Besitz) ans Netz. Inhalt war eine kleinere rote Webseite (http://www.phobeus.de/hosting/olddgl/) mit einem Forum auf einem Lycos-Account. Das Projekt wurde DGL genannt (ist Jemandem schon aufgefallen wie unsinnig der Name ist? Deutsche/Delphi Gomputer/Graphic Libary/Community? *sg) und wurde allgemein mit einem herzhaften Lachen aufgenommen. Die Tatsache, dass ein Direct3D-Programmierer plante, mit einer neuen OpenGL-Seite am ersten April ans Netz zu gehen, schien etwas belustigendes zu haben.<br /> <br /> Was man über die Grafik-Community von Delphi im Jahre 2002 wissen sollte ist, dass Neobrothers.de ein zentrales Forum war in dem sich die Leute zum Sprechen trafen. Die Projekte selbst waren jedoch meist dezentral und jeder Entwickler / jedes Team werkelte im Stillen an seiner Arbeit herum. In der Tat beobachtete ich damals, dass viele Leute mehr Arbeit in Ihre Webseiten steckten als in die eigentliche Programmierung. DGL sollte anderes sein und ein wirkliches Portal sein. Warum muss jeder eine Webseite haben, die nur spärlich verlinkt ist, wenn es doch einen zentralen Ort geben kann an dem man das Wissen einfach zusammenträgt?<br /> <br /> Bereits Ende April hatte DGL rund 20 Besucher täglich und lag damit weit über dem, was wir anfangs geschätzt hatten. Die Folge davon war, dass das Forum auf Grund des „hohen“ Traffic oftmals abends bereits gar nicht mehr erreichbar war. PHP-Webspace war damals noch recht teuer. Also kam es u.a. dazu, dass das Forum von DGL zwischenzeitlich bei Untergrund-Spiele (dem alten unter Krawall-Hosting), quellcodes.de und einem Cobal-Server lag. Ganz vereinzelt findet man noch in sehr alten Dateien unsere alte URL: http://dgl.quellcodes.de/. Keine dieser Seiten existiert heute noch so.<br /> <br /> Bereits im Mai 2002 bekam ich eine ziemlich ernüchternde Mail von einem Entwickler, der mir bis dahin in der Szene nicht bekannt war: Lithander. Er ließ sich über das schreckliche Design der roten Seite aus und dass man da doch sicherlich etwas besser machen könnte. Tja... dauerte keinen Tag, da hatte er einen neuen Job und es entstand das Design von DGL, das bis heute auf dem Server liegt – wenngleich die Technik dahinter mehrfach überarbeitet wurde. Kurze Zeit darauf erhielt ich eine E-Mail von Delphic, der mir anbot ein Tutorial über Landschafts-Rendering zu schreiben. Kaum zu glauben, aber ich habe damals (auf Grund bisheriger Erfahrungen) das ganze für einen schlechten Scherz gehalten und bin umso mehr überrascht gewesen, als plötzlich wirklich ein Tutorial bei mir im Postfach lag. Bereits zu dieser Zeit war Sebo nicht mehr wirklich für DGL aktiv (deswegen findet man auch kaum etwas von ihm), allerdings wurden Lithander und Delphic ins Team aufgenommen.<br /> <br /> Von da an wuchs DGL mit einer ziemlichen Geschwindigkeit. Ich selbst kann nur darüber schmunzeln, dass wir einst mit 10 MB Traffic am Tag Probleme hatten, ein Jahr später wurde bereits die 1,5 GB-Grenze gesprengt. Inzwischen kommt das gesamte DGL-Netz auf knapp 20 GB Traffic. Oftmals blicke ich mit einer Träne im Auge zurück auf das alte DGL, das sehr familiär gewesen ist – bei dem sich die Mitglieder fast alle mehr oder minder noch persönlich kannten. Dies ist inzwischen wohl kaum mehr möglich und der logistische Aufwand für die Community ist erheblich gestiegen. Dennoch ist es schön zu sehen, dass auch noch bei einer solch großen Seite sehr viele Leute da sind, die ebenso wie zur Gründungszeit bereit sind etwas für die Community beizutragen.<br /> <br /> DGL ist eine Community die aus einer Laune heraus entstanden ist, als April-Scherz abgetan wurde und dennoch etwas sinnvolles wurde ;)<br /> <br /> ===Legendäre Threads===<br /> <br /> Im DGL Forum wurden bereits viele interessante Themen diskutiert. Diese wurden im Artikel [[BestOfDGL]] gesammelt. Ein Blick hinein lohnt sich sicherlich.<br /> <br /> ===Aprilscherze===<br /> DGL selbst wurde ursprünglich selbst als Aprilscherz angesehen. Mittlerweile weiß man, dass es mehr war als ein Scherz.<br /> Die Aprilscherze behalten aber ihren Stellenwert in der Community. Zwischen 0.00 und 1.00 Uhr erscheint an jedem 1. April ein erschreckender Newsbeitrag von Phobeus, der den Untergang des Abendlandes, zumindest aber sämtlicher Menschenrechte prophezeit bzw. als bereits vollzogen darstellt. Die News wird immer mit vielen Links zu echten Ereignissen und Schlagwörtern wie &quot;CIA&quot;, &quot;NSA&quot;, &quot;EU-Kommission&quot;, aber immer auch mit Bezug auf die OpenGL-Entwicklung (&quot;GL_ARB_QAIDA&quot;) gewürzt, so dass es einem zuerst beim Lesen, und dann nach der Auflösung und Präsentation der erschreckend harten Fakten kalt den Rücken herunterläuft.<br /> <br /> ====Bisherige April-News====<br /> 1. April 2008: [http://www.delphigl.com/forum/viewtopic.php?t=7374 Breaking News: OpenGL heißt nun FGF] <br /> :Phobeus verkündet die tolle Nachricht, dass sich Microsoft entschlossen habe DirectX mit OpenGL zusammen zu führen.<br /> <br /> 1. April 2007: [http://www.delphigl.com/forum/viewtopic.php?t=6495 Investment opportunity für DGL] <br /> :Phobeus entschließt sich DGL kostenpflichtig zu machen. Denn &quot;Es kann [...] nicht sein, dass ich für meine Ausbildung bezahlen muss und gleichzeitig frei Wissen weitergebe&quot;.<br /> <br /> 1. April 2006: [http://www.delphigl.com/forum/viewtopic.php?t=5398 Sicherheitsrichtlinie im Schnellverfahren] <br /> :Die NSA platziert Backdoors in fast allen Systemen, darunter die OpenGL-Extension &quot;GL_ARB_QAIDA&quot; - alle persönlichen Daten sollen im Klartext zu entsprechenden Stellen weitergeleitet werden...<br /> <br /> 1. April 2005: [http://www.delphigl.com/forum/viewtopic.php?t=3993 Ein schwarzer Tag...] <br /> :Softwarepatente machen fast alle Internetangebote von Open-Source-Gruppen illegal. Erste Homepages gehen bereits vom Netz.<br /> <br /> 1. April 2003: [http://www.delphigl.com/forum/viewtopic.php?t=1745 Phobeus erklärt Rücktritt] <br /> :Die Seite fabriziert zuviel Stress für Phobeus. Deshalb erklärte er seinen Rücktritt als Admin und wollte sich von nun an seiner neuen Leidenschaft &quot;Datenbanken&quot; zuwenden und dafür eine neue Comunity gründen: Die &quot;Deutsche Datenbank-Programmierer Community&quot; DDPC.<br /> <br /> ===Die Community aktuell===<br /> Seit Mitte 2005 kam neben '''OpenGL''' vor allem '''SDL''' als Thema in der DGL Community auf. Plattformunabhängige Programmierung wurde dadurch zunehmend häufiger ein Ziel der DGLer, was im Start der Übersetzung der [[SDL-Funktionsübersicht|SDL-Dokumentation im DGL-Wiki]] gipfelte.<br /> <br /> Des weiteren entwickelte sich DGL von einer &quot;Randgruppen-Randgruppe&quot; (Zitat: Phobeus) hin zu einem OpenGL-Forum, unabhängig welcher Sprache man den Vorzug gibt. Zwar sind die '''Delphi'''- bzw. '''FPC'''-Programmierer immer noch in der Überzahl (ca.60% Jan.2009), aber auch '''C++'''ler, '''C#'''- und '''Java'''-Programmierer sieht man häufiger. Neben der Vielfalt an Programmiersprachen herrscht auch eine große &quot;kulturelle&quot; Vielfalt. Neben 13jährigen Schülern, Mathematikstudenten und Berufsinformatikern aus Deutschland findet man auch Mitglieder aus dem deutsch und nichtdeutschsprachigen Ausland.<br /> <br /> 2009 wurden erstmals die [[DGL_Award|DelphiGL Awards]] verliehen, um die Mitglieder auszuzeichnen, welche besonders gute Projekte, Projektpflege oder Communityarbeit geleistet haben.<br /> <br /> <br /> DGL ist aber nicht nur als Forum aktiv. Zur Zeit bestreitet DelphiGL.com 3 Großprojekte:<br /> *'''[[Hauptseite|DGL-Wiki]]'''<br /> :Das DGL-Wiki ist das wohl '''größte Projekt''' der DGL, denn es bündelt das Wissen vieler OpenGLer und stellt es in deutscher Sprache Interessierten zur Verfügung. (Sie befinden sich gerade im DGL-Wiki ;-)) Neben diesem altruistischen Effekt hilft das Wiki auch, die Wartbarkeit zu erhöhen. Folge dessen ist, dass Fehler, die von unseren Mitgliedern gefunden werden, sofort berichtigt werden können.<br /> <br /> :Im DGL-Wiki findet man unsere [[Tutorial]]s, [[OpenGL-Funktionsübersicht|OpenGL Funktionen]], [[Hintergrundwissen]], [[Link]]s und vieles vieles mehr. Auch eine Sammlung mit [[Shadersammlung|Shadern]] und [[Materialsammlung|Materialien]] ist vorhanden.<br /> <br /> *'''[[DGLSDK]]'''<br /> :Der DGLSDK ist das '''hilfreichste Projekt''' der DGL-Comunity. Bereits 2003 war eine erste Version verfügbar, entwickelte sich aber nicht wie erhofft. Seit 2005 ist nun eine verbesserte und aktualisierte Version verfügbar, die Einsteigern in die OpenGL-Programmierung mit Delphi bzw. FPC alle nötigen Werkzeuge nicht nur an die Hand gibt, sondern auch gleich noch einrichtet. Mit dabei ist unter anderem der [[DGLOpenGL.pas|DGL-OpenGL Header]] welcher dem Delphi eigenen Header unbedingt vorzuziehen ist.<br /> <br /> *'''[[DGLOpenGL.pas]]'''<br /> :Das '''nützlichste Projekt''' und gleichzeitig unser Aushängeschild ist der DGL OpenGL Header. Dieser ist innerhalb der Delphiszene für seine Aktualität und Nutzerfreundlichkeit bekannt. Seit Jahren bietet der DGL Header die Funktionen, die der original Delphi Header von Borland nie bieten konnte. Insbesondere unser Mitglied '''Lossy eX''' hat sich neben Anderen um die Weiterentwicklung und Pflege verdient gemacht.<br /> <br /> ===Rund um DelphiGL===<br /> <br /> ====DGL-Chat====<br /> Schnelle Hilfe und ab und an auch Themenabende gibt es im DGL-Chat. Datailierte Informationen wo ihr ihn findet stehen im Artikel '''[[DGL-Chat]]'''. Für alle Chat unerprobten welche keinen IRC-Client auf ihrem Rechner haben, bietet DelphiGL.com auch einen browsergestützten Chatclient an.<br /> <br /> ====Projekteecke====<br /> Was herauskommen kann, wenn die Mitglieder von DelphiGL.com in die Tasten hauen, kann in der [[DGL Projekte|'''DGL Projekteecke''']] betrachtet werden. Auch wenn die Übersicht nur einen Teil der entstandenen Arbeiten zeigt, sind doch einige recht schöne Ergebnisse dabei.<br /> <br /> ====DelpiGL kämpft gegen AIDS und Krebs====<br /> DelphiGL hilft mit beim [http://www.worldcommunitygrid.org/ World Community Grid]. Diese Organisation stellt eine Software bereit mit der man seine ungenutzte Rechenzeit der Wissenschaft spenden kann. Das Programm läuft im Hintergrund und berechnet z.B. Wirkstoffmolekülstrukturen für AIDS-Medikamente. Das beste aber ist: euer Rechner läuft dadurch nicht langsammer, denn es wird nur ungenutzte Rechenzeit benutzt. Ladet euch doch einfach auch das Tool herunter.<br /> <br /> Nachdem ihr euch beim WCG registriert habt könnt ihr einem Team beitreten. Als DelphiGL-Supporter seid ihr in unserem Team (TeamID: &quot;DGL&quot;) natürlich herzlich willkommen. Wer sich für die '''Teamstatistik''' interessiert kann diese [http://www.worldcommunitygrid.org/team/viewTeamInfo.do?teamId=81JW9RQQGQ1 hier] finden.<br /> <br /> Mittlerweile wird DGL beim World Community Grid als &quot;Partner&quot; geführt.<br /> <br /> ===Historie im Überblick===<br /> Die nachfolgende Tabelle versucht, aus den Newsmeldungen die im Forum von DelphiGL.com zu finden sind, zumindest ausschnittsweise die Geschichte von DelphiGL.com zu rekonstruieren.<br /> <br /> [[Bild:DGL_Map.jpg|right|framed|Die [http://www.frappr.com/delphigl '''Original DGL-Map'''] gibt euch einen Überblick, wo die DGL-Mitglieder wohnen.]]<br /> <br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} <br /> !Datum||Mitglieder&lt;br&gt; bis ''Datum''||Veränderungen/Ereignisse &lt;br&gt; bis ''Datum''<br /> |- align = &quot;center&quot;<br /> |01.04.2002||0||DelphiGL wird gegründet<br /> |- align = &quot;center&quot;<br /> |01.06.2002||13||Forum geht online<br /> |- align = &quot;center&quot;<br /> |01.07.2002||22||erste OpenGL &lt;-&gt; Direct3D Schlammschlacht<br /> |- align = &quot;center&quot;<br /> |01.08.2002||31||Member Forum&lt;br&gt;<br /> Erste Idee Page ins englische zu übersetzen (per McClaw)<br /> |- align = &quot;center&quot;<br /> |01.09.2002||42||Erster Umzug von DGL&lt;br&gt;<br /> Spruch des Tages<br /> |- align = &quot;center&quot;<br /> |01.10.2002||58||SchodMC wird Mod&lt;br&gt;<br /> DGL-Upload-Center&lt;br&gt;<br /> Poll&lt;br&gt;<br /> Recent Uploads&lt;br&gt;<br /> Featured Sites&lt;br&gt;<br /> Bild der Woche&lt;br&gt;<br /> Snippets<br /> |- align = &quot;center&quot;<br /> |01.11.2002||78||TexturenTutorial&lt;br&gt;<br /> Foren FAQ<br /> &lt;br&gt;Poll Archiv<br /> |- align = &quot;center&quot;<br /> |01.12.2002||87||DelphiGL.com Domain&lt;br&gt; <br /> Kommentare zu Newsmeldungen<br /> |- align = &quot;center&quot;<br /> |01.01.2003||106||Neues DGL Logo&lt;br&gt;<br /> '''''100 Mitglieder-Marke erreicht'''''<br /> |- align = &quot;center&quot;<br /> |01.02.2003||123||Umzug auf neuen Server&lt;br&gt;<br /> Sascha Willems (SonOfSatan / SOS) wird Mod&lt;br&gt;<br /> Tutorials als CHM-Version<br /> |- align = &quot;center&quot;<br /> |01.03.2003||136||<br /> |- align = &quot;center&quot;<br /> |01.04.2003||147||Bomberman Tutorial 2<br /> |- align = &quot;center&quot;<br /> |01.05.2003||159||Projekteforum eingerichtet<br /> &lt;br&gt;Phobeus stellt Firefox vor (damals Firebird)<br /> |- align = &quot;center&quot;<br /> |01.06.2003||175||<br /> |- align = &quot;center&quot;<br /> |01.07.2003||196||<br /> |- align = &quot;center&quot;<br /> |01.08.2003||212||IE erkennt DGL als nicht vertrauensvoll ;-)&lt;br&gt;<br /> Flooding durch MS-Bots<br /> |- align = &quot;center&quot;<br /> |01.09.2003||223||Ausfall der Domain<br /> |- align = &quot;center&quot;<br /> |01.10.2003||245||<br /> |- align = &quot;center&quot;<br /> |01.11.2003||265||<br /> |- align = &quot;center&quot;<br /> |01.12.2003||277||Erster IRC-Chat<br /> |- align = &quot;center&quot;<br /> |01.01.2004||296||<br /> |- align = &quot;center&quot;<br /> |01.02.2004||308||<br /> |- align = &quot;center&quot;<br /> |01.03.2004||323||<br /> |- align = &quot;center&quot;<br /> |01.04.2004||347||Borland Developer Network und <br /> Code Central News&lt;br&gt;<br /> W32.Beagle.J@MM Wurm nimmt DGL-Identität an.<br /> |- align = &quot;center&quot;<br /> |01.05.2004||361||<br /> |- align = &quot;center&quot;<br /> |01.06.2004||378||dglOpenGL.pas - Version 1.4<br /> |- align = &quot;center&quot;<br /> |01.07.2004||403||'''DGL Wiki gestartet'''<br /> |- align = &quot;center&quot;<br /> |01.08.2004||421||Atom Feed<br /> |- align = &quot;center&quot;<br /> |01.09.2004||438||dglOpenGL.pas - Version 1.4B&lt;br&gt;'''DGL Wiki hat 100 Artikel'''<br /> |- align = &quot;center&quot;<br /> |01.10.2004||451||dglOpenGL.pas goes FreePascal<br /> |- align = &quot;center&quot;<br /> |01.11.2004||469||<br /> |- align = &quot;center&quot;<br /> |01.12.2004||493||.Net Forum<br /> |- align = &quot;center&quot;<br /> |01.01.2005||512||dglOpenGL.pas - Version 1.6&lt;br&gt;<br /> '''''500 Mitglieder-Marke erreicht'''''<br /> |- align = &quot;center&quot;<br /> |01.02.2005||531||dglOpenGL.pas - Version 1.7&lt;br&gt;'''DGL Wiki hat 250 Artikel'''<br /> |- align = &quot;center&quot;<br /> |01.03.2005||552||<br /> |- align = &quot;center&quot;<br /> |01.04.2005||570||Sascha Willems (&gt;4000 Beiträge) verabschiedet sich aus dem Forum.<br /> |- align = &quot;center&quot;<br /> |01.05.2005||586||<br /> |- align = &quot;center&quot;<br /> |01.06.2005||604||<br /> |- align = &quot;center&quot;<br /> |01.07.2005||617||DGLSDK 2005.1<br /> |- align = &quot;center&quot;<br /> |01.08.2005||635||<br /> |- align = &quot;center&quot;<br /> |01.09.2005||661||Quake3Delphi<br /> |- align = &quot;center&quot;<br /> |01.10.2005||677||Diskussion zum Thema &quot;Windows Vista &amp; OpenGL&quot;<br /> |- align = &quot;center&quot;<br /> |01.11.2005||705||<br /> |- align = &quot;center&quot;<br /> |01.12.2005||729|| '''DGL Wiki hat 500 Artikel'''<br /> |- align = &quot;center&quot;<br /> |01.01.2006||767|| '''DGL Wiki Phasen 1 u. 2 abgeschlossen'''&lt;br&gt; Weihnachtsaktion: Portierung der DGL-Tutorials ins Wiki &lt;br&gt; DGL-Mitglieder starten DGL-Map bei &quot;Frappr.com&quot;<br /> |- align = &quot;center&quot;<br /> |01.02.2006||797||<br /> |- align = &quot;center&quot;<br /> |01.03.2006||832|| Borland will sich von seiner IDE-Sparte trennen<br /> |- align = &quot;center&quot;<br /> |01.04.2006||863|| Windows Vista soll nun doch OpenGL voll unterstützen&lt;br&gt;'''Wiki Phase III abgeschlossen''' &lt;br&gt; '''Wiki Phase V vorzeitig abgeschlossen'''<br /> |- align = &quot;center&quot;<br /> |01.05.2006||891|| SGI beantragt Gläubigerschutz<br /> |- align = &quot;center&quot;<br /> |01.06.2006||912|| Neuer DGL Poll<br /> |- align = &quot;center&quot;<br /> |01.07.2006||933|| DGLSDK 2006.1<br /> |- align = &quot;center&quot;<br /> |01.08.2006||950|| Serverumzug (größte Wartungsarbeiten seit Gründung von DGL)<br /> |- align = &quot;center&quot;<br /> |01.09.2006||977|| Änderungen im DelphiGL Team<br /> |- align = &quot;center&quot;<br /> |01.10.2006||991|| Turbodelphi erscheint<br /> |- align = &quot;center&quot;<br /> |01.11.2006||1021|| DGL wird Partner des World Community Grids&lt;br&gt;<br /> '''''1000 Mitglieder-Marke erreicht'''''<br /> |- align = &quot;center&quot;<br /> |01.12.2006||1045||<br /> |- align = &quot;center&quot;<br /> |01.01.2007||1067|| Tutorial Raytracing Grundlagen<br /> |- align = &quot;center&quot;<br /> |01.02.2007||1106|| Tutorial Raytracing Grundlagen 2 &lt;br&gt; DOS Angriff auf DelphiGL&lt;br&gt;'''Wiki Phase VI vorzeitig abgeschlossen'''<br /> |- align = &quot;center&quot;<br /> |01.03.2007||1131|| SDL_Rwops Tutorial<br /> |- align = &quot;center&quot;<br /> |01.04.2007||1164|| [[DGL_Projekte]]<br /> |- align = &quot;center&quot;<br /> |01.05.2007||1182|| DGLOpenGL.pas V 2.1&lt;br&gt;[[BestOfDGL]]<br /> |- align = &quot;center&quot;<br /> |01.06.2007||1201|| <br /> |- align = &quot;center&quot;<br /> |01.07.2007||1223||<br /> |- align = &quot;center&quot;<br /> |01.08.2007||1248||&quot;Spekulationen über OpenGL3.0&lt;br&gt;Tutorial_Softwareentwicklung3&quot;<br /> |- align = &quot;center&quot;<br /> |01.09.2007||1261||<br /> |- align = &quot;center&quot;<br /> |01.10.2007||1284||'''DGL Wiki hat 750 Artikel'''&lt;br&gt;Tutorial_Kollisionserkennung&lt;br&gt;Tutorial Framebufferobject<br /> |- align = &quot;center&quot;<br /> |01.11.2007||1309||Forenstruktur überarbeitet&lt;br&gt;Tutorial Wassereffekt<br /> |- align = &quot;center&quot;<br /> |01.12.2007||1330||<br /> |- align = &quot;center&quot;<br /> |01.01.2008||1347||<br /> |- align = &quot;center&quot;<br /> |01.02.2008||1372||<br /> |- align = &quot;center&quot;<br /> |01.03.2008||1393||DGL Suche für Firefox&lt;br&gt;1. Kollisionstutorial<br /> |- align = &quot;center&quot;<br /> |01.04.2008||1411||Bundesverfassungsgericht erklärt Sicherheit gespeicherter Daten zum Grundrecht<br /> |- align = &quot;center&quot;<br /> |01.05.2008||1437||2. Kollisionstutorial&lt;br&gt;OpenAL Übersicht offiziell als Wikiteil vorgestellt&lt;br&gt;UTF8 Umstellung des Forums gescheitert<br /> |- align = &quot;center&quot;<br /> |01.06.2008||1452||Borland verkauft seine Entwicklungstools (CodeGear)<br /> |- align = &quot;center&quot;<br /> |01.07.2008||1466||3. Kollisionstutorial<br /> |- align = &quot;center&quot;<br /> |01.08.2008||1479||<br /> |- align = &quot;center&quot;<br /> |01.09.2008||1499||Erste Lebenszeichen von OpenGL3.0&lt;br&gt;Shadersammlung im Wiki<br /> |- align = &quot;center&quot;<br /> |01.10.2008||1514||SGI stellt OpenGL Quellcode unter echte OSS Lizenz<br /> |- align = &quot;center&quot;<br /> |01.11.2008||1532||<br /> |- align = &quot;center&quot;<br /> |01.12.2008||1546||Start der Überarbeitung/Aktualisierung der Einsteigertutorials<br /> |}<br /> &lt;/div&gt;<br /> <br /> ==Links==<br /> [[DGLOpenGL.pas|Link zum OpenGL Header von DelphiGL.]]<br /> <br /> [http://www.delphiGL.com http://www.DelphiGL.com - Heimat der DGLer]<br /> <br /> [http://www.frappr.com/delphigl Link zur DGL_Map]<br /> <br /> [[DGL Projekte|Link auf die DGL Projekteecke]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial_StereoSehen&diff=23923 2009-07-23T15:06:17Z

<p>Delphic: -&gt;Delphic</p> <hr /> <div>=Stereo einmal sehen statt hören=<br /> [[Bild:Tutorial_Stereo_anaglyph.jpg|center]]<br /> ==Einleitung==<br /> Viele Tiere haben mit dem Menschen eins gemein: Zwei Augen. Dies kann unterschiedliche Vorteile haben, etwa in zwei Richtungen gleichzeitig sehen zu können, oder, was viel häufiger ist, um räumlich sehen zu können. Die Welt aus zwei leicht unterschiedlichen Blickwinkeln zu sehen ermöglicht es dem Gehirn Abstände und Geschwindigkeiten besser einzuschärtzen, als mit einem Auge. Das es uns auch mit einem Auge gelingt, erkennt man dran, dass das in begrenztem Umfang auch bei Fotos gelingt und wenn wir mit einem geschlossenem Auge durch ein Zimmer laufen trotzdem nicht überall anstossen. Das funktioniert sogar so gut, dass Menschen, die nur stark eingeschränkt oder gar nicht räumlich sehen können, dies gar nicht so selten erst bei Routineuntersuchungen von Augenärzten oder im Verlauf ihrer Musterung erfahren.<br /> <br /> An einer Stelle ist es jedoch egal, ob wir räumlich sehen können oder nicht - beim Spielen und Arbeiten am Computer. Aber 3D Spiele wollen doch gerade eines: uns die Welt möglichst realistisch vor Augen führen. Leider hat der Computer meist nur einen Monitor, wir aber zwei Augen... Und damit Good Bye räumliches Sehen? Nein, nein, so einfach dürfen wir uns nicht geschlagen geben. Tatsächlich fallen mir gleich eine Reihe von Möglichkeiten ein: Stereogramme, wie sie eine Zeit lang modern waren, und in vielen Büchern vorkommen: langes Stieren auf stylisch eingefärbte Buchseiten. Bei 3D-Spielen waren eine Zeit lang 3D-Shutterbrillen beliebt, bei denen jeweils ein Auge abgedunkelt wird, auf dem Monitor für das Auge ein Bild angezeigt und dann gewechselt wird. Zeigt man für jedes Auge ein leicht versetztes Bild an und wechselt die Bilder häufig genug, entsteht für den Betrachter ein 3-Dimensionales Bild der Szenerie. Leider benötigt man für diese Technik schnell schaltende Röhrenmonitore - mit aktuellen TFT Monitoren ist dies, wegen ihrer langsamen Schaltgeschwindigkeiten nicht möglich und statt eines 3D-Bildes entsteht irgend ein wenig aussagekräftiges Geschmiere.<br /> <br /> Das ist noch immer kein Grund, entmutigt zu sein: In Kinofilmen wird noch heute oft die Technik der Anaglyphe eingesetzt. Dabei muss der Betrachter eine 3D-Brille aufsetzen, die vor jedes Auge einen anderen Farbfilter setzt, etwa rot und grün. Bei der Filmaufnahme werden dann zwei überkreuzt filmende Kameras verwendet.<br /> <br /> Der 3D Effekt stellt sich bei den meisten Menschen schnell ein, bei Anderen dauert es ein wenig oder erfordert etwas Übung. Den Effekt gar nicht geniessen können üblicherweise nur stark Schielende, Einäugige und Blinde. Eine wesentliche Einschränkung bei diesem Verfahren ist jedoch, dass das entstehende Bild meist einfarbig, ähnlich einem s/w Film, ist. Der entstehende 3D Effekt gleicht dieses Manko meiner Ansicht nach auf alle Fälle aus - und da wir möglichst Niemanden ausschliessen möchten, unsere Programme zu bestaunen, werden wir unsere Programme sowohl für &quot;normale&quot; Grafikausgabe als auch für 3D-Brillen vorbereiten.<br /> <br /> ==Die 3D-Brille==<br /> Jeder der weitermachen möchte, sollte sich spätestens hier eine 3D-Brille besorgen. Diese gibts z.B. beim Optiker und sollte möglichst einen roten und einen grünen Filter besitzen. Zur Not tuts auch rot-blau, ist jedoch wegen den stark auseinanderliegenden Wellenlängen des roten und blauen Lichtes weniger gut geeignet. Einigen Büchern zu optischen Täuschungen liegen ebenfalls Brillen bei. Solltet ihr keine passende, vorgefertigte Brille finden, könnt ihr sie auch mit etwas Pappe oder Karton und Farbfolien aus dem Bastelladen selbst bauen - oder ganz nobel: mit Filtern aus dem Fotoladen statt ordinären Farbfolien. <br /> [[Bild:Tutorial_Stereo_brille.png|center]]<br /> <br /> ==Projektionen==<br /> Bei der üblichen, perspektivischen Projektion ist die Sache einfach: Man hat ein Auge, einen Öffnungswinkel für die Kamera und die Entfernung für die nahe Clipping-Ebene: <br /> [[Bild:Tutorial_Stereo_perspektivisch.png|center]]<br /> <br /> Beim Stereo-Sehen wird die Sache ein Wenig komplizierter. Da man mit Beiden Augen auf die Projektionsebene Bildschirm schaut, ist diese für beide Augen identisch, jedoch sind die Blickkegel nicht mehr gerade, sondern schief:<br /> [[Bild:Tutorial_Stereo_stereo.png|center]]<br /> <br /> Zu allem überfluss können wir unsere Augen auch noch auf eine bestimmte Entfernung ausrichten, d.h. die Ebene, auf die die Augen eingestellt sind, muss nicht der Entfernung der nahen Clippling-Plane entsprechend - das Problem können wir jedoch ganz einfach mithilfe der Strahlensätze lösen.<br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;...<br /> var<br /> zNear, zFar, Oeffnungswinkel, Augenabstand, Zielweite : Single;<br /> ...<br /> const<br /> PBufSize = 1024; //Seitenläne des PBuffers<br /> var<br /> SVerh, ROeffnung : Single;<br /> Breitenhaelfte, NeardZielweite : Single;<br /> left, right, top, bottom : Single;<br /> <br /> procedure CalcValues;<br /> begin<br /> ROeffnung := DegToRad(Oeffnungswinkel / 2); //Halber Öffnungswinkel in RAD<br /> Breitenhaelfte := zNear * Tan(ROeffnung); //Halbe Breite der Proj. Ebene<br /> NeardZielweite := zNear / Zielweite; <br /> end;<br /> <br /> begin<br /> if Opt.Stereo then //Stereo Modus<br /> begin<br /> glViewport(0, 0, ClientWidth, ClientHeight);<br /> //Projektionsmatrix resetten<br /> glMatrixMode(GL_PROJECTION);<br /> glLoadIdentity();<br /> <br /> SVerh := ClientWidth/ClientHeight; //Breite zu Höhe<br /> CalcValues;<br /> <br /> //Ränder der Projektionsebene für glFrustum<br /> left := - SVerh * Breitenhaelfte - 0.5 *Augenabstand*NeardZielweite;<br /> right := SVerh * Breitenhaelfte - 0.5 *Augenabstand*NeardZielweite;<br /> top := Breitenhaelfte;<br /> bottom := -Breitenhaelfte;<br /> glFrustum(left, right, bottom, top, zNear, zFar);<br /> <br /> glMatrixMode(GL_MODELVIEW);<br /> glLoadIdentity;<br /> <br /> //PBuffer erzeugen und aktivieren, wenn noch nicht geschehen<br /> if not Assigned(PBuffer) then<br /> begin<br /> PBuffer := TPixelBuffer.Create(PBufSize, PBufSize, DC, RC, Self);<br /> wglShareLists(RC, PBuffer.RC);<br /> PBuffer.Enable;<br /> InitGl;<br /> end<br /> else<br /> PBuffer.Enable;<br /> <br /> glViewport(0, 0, PBufSize, PBufSize);<br /> //Projektionsmatrix resetten<br /> glMatrixMode(GL_PROJECTION);<br /> glLoadIdentity();<br /> <br /> //Diesmal das Frustum in die andere Richtung schiefstellen(+ statt -)<br /> left := - SVerh * Breitenhaelfte + 0.5 *Augenabstand*NeardZielweite;<br /> right := SVerh * Breitenhaelfte + 0.5 *Augenabstand*NeardZielweite;<br /> top := Breitenhaelfte;<br /> bottom := -Breitenhaelfte;<br /> glFrustum(left, right, bottom, top, zNear, zFar);<br /> <br /> glMatrixMode(GL_MODELVIEW);<br /> glLoadIdentity;<br /> <br /> PBuffer.Disable;<br /> end<br /> else<br /> begin<br /> //Normale Ansicht<br /> glViewport(0, 0, ClientWidth, ClientHeight);<br /> //Projektionsmatrix resetten<br /> glMatrixMode(GL_PROJECTION);<br /> glLoadIdentity();<br /> //Perspektivische Darstellung<br /> SVerh := ClientWidth/ClientHeight;<br /> CalcValues;<br /> //Hier wird nichts verschoben<br /> left := - SVerh * Breitenhaelfte;<br /> right := SVerh * Breitenhaelfte;<br /> top := Breitenhaelfte;<br /> bottom := -Breitenhaelfte;<br /> glFrustum(left, right, bottom, top, zNear, zFar);<br /> <br /> glMatrixMode(GL_MODELVIEW);<br /> glLoadIdentity;<br /> <br /> end;<br /> end;<br /> ...&lt;/source&gt;<br /> <br /> <br /> ==Und Rendern?==<br /> Nun müssen wir nur noch zwei Bilder anzeigen. Die einfachste Möglichkeit dürfte sein, ein Bild für das linke Auge in einen PBuffer oder sonstige Textur zu rendern, dann das Bild für das rechte Auge in den Hintergrundpuffer. Der Inhalt des PBuffers wird dann mittels Blending auch in den Hintergrundpuffer gezeichnet und voila. Wir haben zwei verschiedene Bilder auf dem Schirm. Zu beachten ist noch, dass die Farben mittels [[glColorMask]] beim Rendern maskiert werden müssen - wir wollen ja für die beiden Augen unterschiedliche Farben anzeigen. <br /> <br /> &lt;source lang=&quot;pascal&quot;&gt;procedure TStereoForm.Render;<br /> procedure RenderScene;<br /> begin<br /> //kein glLoadIdentity am Anfang! Das muss vorher gemacht worden sein -<br /> //für die Augen muss ja bereits verschoben worden sein. Also Achtung.<br /> //Brav mit Push und Pop Matrix arbeiten.<br /> ...<br /> end;<br /> <br /> var<br /> Error : glUInt;<br /> begin<br /> if (Opt.Stereo) and (Assigned(PBuffer)) then<br /> begin<br /> //Stereo Modus<br /> PBuffer.Enable;<br /> glClearColor(0.0, 0.0, 0.0, 0.0);<br /> glClear(GL_DEPTH_BUFFER_BIT or GL_COLOR_BUFFER_BIT);<br /> <br /> glLoadIdentity;<br /> glTranslatef(Augenabstand/2, 0, 0);<br /> <br /> //linkes Auge bekommt grün und blau - das sollte über Optionen wählbar sein<br /> glColorMask(false, true, true, true);<br /> RenderScene;<br /> PBuffer.Disable;<br /> <br /> glClearColor(0.0, 0.0, 0.0, 0.0);<br /> glClear(GL_DEPTH_BUFFER_BIT or GL_COLOR_BUFFER_BIT);<br /> <br /> glLoadIdentity;<br /> glTranslatef(-Augenabstand/2, 0, 0);<br /> <br /> //rechtes Auge bekommt nuir rot<br /> glColorMask(true, false, false, true);<br /> RenderScene;<br /> <br /> //Und zusammenblenden<br /> glColorMask(true, true, true, true);<br /> glDepthFunc(GL_ALWAYS);<br /> glMatrixMode(GL_PROJECTION);<br /> glPushMatrix;<br /> glLoadIdentity;<br /> glOrtho(0, 1, 1, 0, -1.0, 1.0);<br /> <br /> glMatrixMode(GL_MODELVIEW);<br /> glLoadIdentity;<br /> <br /> glDisable(GL_LIGHTING);<br /> glEnable(GL_TEXTURE_2D);<br /> PBuffer.Bind;<br /> glEnable(GL_BLEND);<br /> glBlendFunc(GL_ONE, GL_ONE);<br /> glBegin(GL_QUADS);<br /> glTexCoord2f(1, 0); glVertex2f(1,1);<br /> glTexCoord2f(1, 1); glVertex2f(1,0);<br /> glTexCoord2f(0, 1); glVertex2f(0,0);<br /> glTexCoord2f(0, 0); glVertex2f(0,1);<br /> glEnd();<br /> glDisable(GL_BLEND);<br /> <br /> glEnable(GL_LIGHTING);<br /> glDisable(GL_TEXTURE_2D);<br /> PBuffer.Release;<br /> <br /> glMatrixMode(GL_PROJECTION);<br /> glPopMatrix;<br /> glMatrixMode(GL_MODELVIEW);<br /> glDepthFunc(GL_LESS);<br /> end<br /> else<br /> begin<br /> //&quot;Mono&quot; Modus<br /> glClearColor(0.0, 0.0, 0.0, 0.0);<br /> glClear(GL_DEPTH_BUFFER_BIT or GL_COLOR_BUFFER_BIT);<br /> <br /> glLoadIdentity;<br /> RenderScene;<br /> end;<br /> ...<br /> end;&lt;/source&gt;<br /> <br /> <br /> ==Und 3D-Shutterbrillen?==<br /> Wer eine 3D-Sutterbrille und entsprechendes Equipment zuhause hat, kann seine Anwendungen auch für diese anpassen. Einige Grafikkarten haben bereits passende Treiber, die die Ausgabe der Programme automatisch anpassen. Wer das nicht will, sollte sich einmal mit Stereo-OpenGl auseinandersetzen. Bei der dglOpenGl genügt es, den Rendering Context mit der Option opStereo zu erstellen. Mit [[glDrawBuffer]]('''GL_BACK_LEFT'''/'''GL_BACK_RIGHT''') kann dann für jedes Auge in einen anderen Puffer gerendert werden.<br /> <br /> ==Abschluss==<br /> Ich hoffe euch hat dieser kleine Exkurs gefallen. Vielleicht läuft einem ja mal das eine oder andere Programm über den Weg, wo man die Wahl zwischen Tiefensehen und normaler Ansicht hat - mich würde es jedenfalls freuen, zumal es ja nicht wirklich schwer ist, seine Programme entsprechend anzupassen und es doch ein wesentlich anderes Gefühl der Szene erzeugt, als üblicherweise vor dem Computer. Ich bin jedenfalls gespannt, erwarte mir aber nicht allzuviel - bislang war das Feedback und eure Demos ja sehr bescheiden. Wo ich da nur immer die Motivation hernehme, euch mit ein paar neuen Ideen zu versorgen? ;-D<br /> <br /> <br /> <br /> Euer Delphic<br /> <br /> <br /> <br /> ==Kleine Anmerkung am Rande==<br /> Nach Fertigstellung des Tutorials wurde ich darauf aufmerksam gemacht, daß man um den Einsatz des P-Buffers herumkommt - was Geschwindigkeit und Kompatibilität erhöht. Man muss nur zwischen den glColorMask Befehlen einmal den Tiefenpuffer leeren. In etwa läuft das ganze dann wie folgt:<br /> <br /> private void RenderMono()<br /> {<br /> RenderSettings rs = new RenderSettings();<br /> rs.Mono(RenderPanel.ClientRectangle.Width, RenderPanel.ClientRectangle.Height);<br /> <br /> GL.Clear(GL.COLOR_BUFFER_BIT | GL.DEPTH_BUFFER_BIT);<br /> //Szene Rendern<br /> }<br /> <br /> private void RenderStereo()<br /> {<br /> GL.Clear(GL.COLOR_BUFFER_BIT | GL.DEPTH_BUFFER_BIT);<br /> <br /> RenderSettings rs = new RenderSettings();<br /> rs.Stereo(true, RenderPanel.ClientRectangle.Width, RenderPanel.ClientRectangle.Height);<br /> GL.ColorMask(1, 0, 0,1);<br /> //Szene Rendern<br /> <br /> rs.Stereo(false, RenderPanel.ClientRectangle.Width, RenderPanel.ClientRectangle.Height);<br /> GL.Clear(GL.DEPTH_BUFFER_BIT);<br /> GL.ColorMask(0, 1, 1,1);<br /> //Szene Rendern<br /> <br /> <br /> if (GL.GetError() != GL.NO_ERROR)<br /> {<br /> }<br /> }<br /> <br /> private void Render()<br /> {<br /> if (rc != null)<br /> {<br /> GL.PushAttrib(GL.ALL_ATTRIB_BITS);<br /> GL.ClearColor(0.0f, 0f, 0f, 1f);<br /> if (stereo)<br /> RenderStereo();<br /> else<br /> RenderMono();<br /> rc.SwapBuffers();<br /> GL.PopAttrib();<br /> }<br /> }<br /> <br /> Die rs.stereo(true/false, ...) Befehle laden die benötigten Matrizen für das linke bzw. rechte Auge.<br /> <br /> == Dateien ==<br /> * {{ArchivLink|file=tut_stereo_delphi_vcl|text=Delphi-VCL-Quelltext zum Tutorial}}<br /> <br /> {{TUTORIAL_NAVIGATION|[[Tutorial_StencilSpiegel]]|[[Tutorial_Alphamasking]]}}<br /> <br /> [[Kategorie:Tutorial|StereoSehen]]</div>

Delphic https://wiki.delphigl.com/index.php?title=Tutorial&diff=23922 2009-07-23T15:05:36Z

<p>Delphic: -&gt;Delphic</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=&quot;100%&quot;<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 &quot;Delphiprogrammierung&quot;. 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 /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;100%&quot;<br /> !width=&quot;15%&quot;|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 /> &lt;/div&gt;<br /> <br /> == Einsteiger-Tutorials ==<br /> &lt;div align=&quot;center&quot;&gt;<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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Quickstart]] (VCL)<br /> {{Level_1}} <br /> |[[Bild:Tutorial_Lektion1.gif|right]] &quot;Quickstart: OpenGL &amp; Delphi&quot;&lt;br&gt; <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]] &quot;Nicht zu weit aus dem Fenster lehnen&quot;&lt;br&gt; <br /> Dieses Tutorial von Magellan ist für alle Neueinsteiger gedacht. Hier werden Grundlagen von &quot;Was ist OpenGL&quot; bis zu &quot;Wie initialisiere ich OpenGL?&quot; besprochen.<br /> |-<br /> ![[Tutorial Lektion 2]]<br /> {{Level_1}} <br /> |[[Bild:Tutorial_Lektion2.jpg|right]] &quot;Entdeckung einer neuen Welt&quot;&lt;br&gt; <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]] &quot;Eine Welt des Grauens?&quot;&lt;br&gt; <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]] &quot;Texturen, Tapeten und Ihre Tücken&quot;&lt;br&gt; <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]] &quot;Artenvielfalten und Ihre Folgen&quot;&lt;br&gt; <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]] &quot;Dark Engine&quot;&lt;br&gt; <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]] &quot;Verblendet!&quot;&lt;br&gt; <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]] &quot;Das Wesen von hell und dunkel - Licht&quot;&lt;br&gt; <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]] &quot;2D mit OpenGL&quot;&lt;br&gt; <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]] &quot;Matrix2 - Matrizen und Matrixmanipulationen&quot;&lt;br&gt; <br /> Das Thema Matrizen stellt OpenGL-Einsteiger regelmäßig vor &quot;unlösbare&quot; Aufgaben:&lt;br&gt;<br /> ''Wieso dreht sich der Würfel so komisch, und nicht um sich selbst?''&lt;br&gt; <br /> ''Wieso verschiebt OpenGL die Kugel denn dahin, und nicht dorthin?''&lt;br&gt;<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 /> &lt;/div&gt;<br /> <br /> == Grundlagen-Tutorials ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Abseits eckiger Welten]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_Abseits_eckiger_Welten.gif|right]] &quot;Abseits eckiger Welten&quot;&lt;br&gt; <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]] &quot;Renderpass - Die Welt daneben&quot;&lt;br&gt; <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]] &quot;Objectselektion A&quot;&lt;br&gt; <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]] &quot;Objektselektion B&quot; &lt;br&gt;<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 TexFilter]]<br /> {{Level_1}} <br /> |[[Bild:Tutorial_TexFilter.jpg|right]] &quot;Texturfilterung - Texturen-Feintuning&quot;&lt;br&gt; <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]] &quot;Dreht sich das Universum um uns? und andere philosophische Fragen&quot;&lt;br&gt; <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 /> &lt;/div&gt;<br /> <br /> == Effekte ==<br /> &lt;div align=&quot;center&quot;&gt;<br /> {|{{Prettytable_B1}} width=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Nebel]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_Nebel.jpg|right]] &quot;DGL Fogging Tutorial&quot;.&lt;br&gt; <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]] &quot;Partikel-Tutorial I&quot;.&lt;br&gt;<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]] &quot;Bumpmapping - Plastisches 2D&quot;.&lt;br&gt; <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]] &quot;Multitexturing&quot;.&lt;br&gt;<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]] &quot;Spiegelungen mit dem Stencil-Buffer&quot;.&lt;br&gt; <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 /> &lt;/div&gt;<br /> <br /> ==Extensions==<br /> {|{{Prettytable_B1}} width=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Cubemap]]<br /> {{Level_3}} <br /> |[[Bild:Tutorial_Cubemap_mini.jpg|right]] &quot;GL_ARB_Texture_Cubemap&quot;.&lt;br&gt; <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]] &quot;GL_ARB_Vertex_Buffer_Object&quot;.&lt;br&gt; <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]] &quot;GL_ARB_Vertex_Program&quot;.&lt;br&gt; <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]] &quot;NV_Occlusion_Query&quot;.&lt;br&gt; <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]] &quot;WGL_ARB_Pixel_Buffer&quot;.&lt;br&gt; <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]] &quot;GL_EXT_FRAMEBUFFER_OBJECT&quot;.&lt;br&gt; <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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial glsl|Tutorial glSlang]]<br /> {{Level_4}} <br /> |[[Bild:Tutorial_glsl1.png|right]] &quot;Einführung in GLSL&quot;.&lt;br&gt; <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]] &quot;GLSL-Ergänzungen und Beispiele&quot;.&lt;br&gt; <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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial pathfinding|Tutorial Pathfinding]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_pathfinding.png|right]] &quot;Pathfinding 1&quot;.&lt;br&gt; <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]] &quot;Pathfinding 2&quot;.&lt;br&gt; <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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Terrain1]]<br /> {{Level_4}} <br /> |[[Bild:Tutorial_Terrain1.gif|right]] &quot;Aussenlandschaften mit System - Heightmaps&quot;.&lt;br&gt; <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]] &quot;Heightmap-Texturen&quot;.&lt;br&gt; <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]] &quot;Terrain im Detail&quot;.&lt;br&gt; <br /> Da größere Landschaften aufgrund der hohen Polygonanzahl sehr aufwändig zu rendern sind erklärt euch Delphic hier, wie man entfernte Dreiecke &quot;zusammenlegen&quot; kann, um Rechenleistung zu sparen.<br /> |-<br /> ![[Tutorial Skyboxen]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_Skybox_Vorschau.jpg|right]] &quot;Skyboxen&quot;.&lt;br&gt; <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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Bomberman1|Tutorial Bomberman 1]]<br /> {{Level_3}} <br /> |[[Bild:Tutorial_Bomberman1.jpg|right]] &quot;Bomberman1 - Codebasis und Editor&quot;.&lt;br&gt; <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]] &quot;Bomberman2 - Der 3D-Bombermanklon (Grundversion)&quot;.&lt;br&gt; <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]] &quot;Softwareentwicklung1 - Objektorientierte Softwareentwicklung mit UML&quot;.&lt;br&gt; <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]] &quot;Softwareentwicklung2 - Objektorientierte Softwareentwicklung mit UML&quot;.&lt;br&gt; <br /> Im zweiten und umfangreichsten Teil der Serie steht das Thema &quot;Klassen&quot; 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]] &quot;Softwareentwicklung3 - Objektorientierte Softwareentwicklung mit UML&quot;.&lt;br&gt; <br /> Im letzten Teil der Serie steht das Thema &quot;Verhalten&quot; 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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Lineare Algebra]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_lineare_Algebra_Preview.jpg|right]] &quot;Vektorrechnung&quot;.&lt;br&gt; <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]] &quot;3d-Mathematik&quot;.&lt;br&gt; <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]] &quot;Objekt gedreht und dennoch nach vorne bewegt&quot;.&lt;br&gt; <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]] &quot;Objekt immer um eigene Achse drehen&quot;.&lt;br&gt;<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]] &quot;Separating Axis Theorem&quot;&lt;br&gt;<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]] &quot;Kollision 1&quot;&lt;br&gt;<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]] &quot;Kollision 2&quot;&lt;br&gt;<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]] &quot;Kollision 3&quot;&lt;br&gt;<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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Modellierung eines Low-Poly Menschen Teil 1]]<br /> {{Level_4}} <br /> |[[Bild:Tutorial_Low-Poly-Mensch1_preview.jpg|right]] &quot;Modellierung eines Low-Poly-Menschen&quot;.&lt;br&gt; <br /> Die Modellierung von organischen &quot;Objekten&quot; 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]] &quot;Kleider machen Leute (UVW-Mapping)&quot;.&lt;br&gt; <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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial Scripting mit JvInterpreterProgram]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_JvInterpreter_preview.png|right]] &quot;Skripting mithilfe der Jedi-Code-Library&quot;.&lt;br&gt; <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]] &quot;Scriptsprachen Teil 1 - Einführung&quot;.&lt;br&gt; <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]] &quot;Scriptsprachen Teil 2 - Virtuelle Computer und Code Erzeugung&quot;.&lt;br&gt;<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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ! [[Tutorial Debugging]]<br /> {{Level_2}} <br /> | [[Bild:Tutorial Debugging.gif|right]] &quot;Debugger benutzen und andere praktische Tipps&quot; &lt;br&gt;<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]] &quot;Komponentenentwicklung&quot; &lt;br&gt;<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]] &quot;Das Prinzip der Dualität&quot;.&lt;br&gt; <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]] &quot;Software-Synthesizer&quot; &lt;br&gt;<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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ![[Tutorial SDL Einstieg]]<br /> {{Level_2}} <br /> |[[Bild:Tutorial_Lektion1.gif|right]] &quot;SDL-Einsteiger-Tutorial&quot;&lt;br&gt; <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 &quot;Quake III&quot; und &quot;Civilisation - Call to Power&quot; 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]] &quot;SDL_RWops-Tutorial&quot;&lt;br&gt;<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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ! [[Tutorial Octree]]<br /> {{Level_1}} <br /> | [[Bild:Tutorial Octree preview.jpg|right]] &quot;Octrees&quot; &lt;br&gt;<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]] &quot;Frustum Culling&quot; &lt;br&gt;<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=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ! [[Tutorial Raytracing - Grundlagen I]]<br /> {{Level_4}} <br /> | [[Bild:Tutorial_RaytracingI_thumb.jpg|right]] &quot;Raytracing - Grundlagen I&quot; &lt;br&gt;<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]] &quot;Raytracing - Grundlagen II&quot; &lt;br&gt;<br /> Die Grundzüge des Raytracings Teil 2 - Einfache Basisobjekte, Transformationen und Phong-Lightning<br /> |}<br /> <br /> == Sonstiges ==<br /> {|{{Prettytable_B1}} width=&quot;100%&quot;<br /> !width=&quot;15%&quot;|Link<br /> !width=&quot;85%&quot;|Beschreibung<br /> |-<br /> ! [[Tutorial GLScene]]<br /> {{Level_1}} <br /> | [[Bild:Tutorial GLScene preview.jpg|right]] &quot;Einführung in GLScene&quot; &lt;br&gt;<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>

Delphic