Textur Mapping

Transcrição

Textur Mapping

DistFracEx3D
Interaktive Visualisierung von Mandelbrotmengen als fraktale Landschaften
Teil 1
Fachhochschule Fulda
Fachbereich Angewandte Informatik und Mathematik
Lehrveranstaltung Graphikprogrammierung und Parallelverarbeitung
Eingereicht von:
Timo Götzelmann
Sturmiusstrasse 6
36037 Fulda
Fulda, 31. März 2004
Interaktive Darstellung von Mandelbrotmengen als fraktale Landschaften, Teil 1
Seite: 1
Inhaltsverzeichnis
Vorwort
3
1.
Struktur des Programms
4
2.
Generierung der Fraktale
4
3.
Generierung der Fraktallandschaft
5
3.1
Umwandlung in ein 3D-Landschaftsmodell
5
3.1.1
Umwandlung Koordinaten
5
3.1.2
Wahl der Primitive
6
3.1.2.1 GL_QUADS vs. GL_QUAD_STRIP
6
3.1.2.2
Betrachtung der Speicherkomplexität
7
3.1.2.3
Kritische Betrachtung
7
3.2
Logarithmierung
8
3.3
Normalisierung der Daten
8
3.4
Glättung der Fraktallandschaft
8
3.4.1
Mittelungsfilter
9
3.4.2
Medianfilter
10
4.
Texturerzeugung
11
4.1
Landschaftstextur
11
4.1.1
Einteilung der Ebenenregionen
11
4.1.2
Synthese der Teiltexturen
12
4.1.3
Spannen nicht erlaubt
13
4.2
Himmelstextur
13
4.2.1
Generierung mittels Fourierreihe
13
4.2.2
Generierung mittels Zufallswerten
15
5.
Optimierungen
17
5.1
Vernachlässigen der Rückseiten
17
5.2
Beseitigen des Flackerns
17
5.3
Nebeleffekt
18
5.4
Anpassung der Sichtweite
18
5.4.1
Maximal mögliche Sichtweite
18
5.4.2
Optimierungen der Sichtweite
19
Timo Götzelmann
Seite: 2
5.5
Textur-Detailstufen
20
5.6
Texturüberlagerung
21
5.7
Bäume
21
6
Ausblick und mögliche Erweiterungen
23
Quellenverzeichnis
25
Anhang
A
Systemvoraussetzungen
26
B
Benutzerdokumentaion
27
B.1
Grundlegende Interaktionsmöglichkeiten
27
B.2
Änderung der Auslösung/ des Anzeigemodus
28
B.3
Zusatzoptionen mittels Mausmenü
28
C
Installation der MPI-Implementierung MPICH 1.2.5 unter Windows NT
30
D
Quellenangaben für Texturen
33
Timo Götzelmann
Seite: 3
Vorwort
Im Rahmen einer Studienarbeit der Veranstaltung „Systemprogrammierung“ habe ich es mir als
Aufgabe gemacht, Mandelbrotmengen als 3D-Fraktallandschaft möglichst anschaulich
darzustellen. Des weiteren soll die Fraktallandschaft interaktiv unter OpenGL steuerbar sein, was
Echtzeitberechnungen bedingt.
Anschaulich bedeutet, dass ich durch einige Manipulationen an den fraktalen Daten eine
möglichst große Ähnlichkeit zu einer realen Landschaft herstelle. Dies verstößt zwar gegen das
Expressivitätskriterium (vgl. [Schu 00/1]), d.h. es bedeutet eine Verfälschung der
Ausgangsdaten, jedoch lassen sich die Daten zum größten Teil zu den Ausgangsdaten
rückführen, d.h. die Manipulationen sind reversibel und damit nicht verheerend.
Des weiteren sind diese Manipulationen im dargelegten Anwendungskontext unbedingt
notwendig, um die Daten auch anschaulich und landschaftsähnlich darzustellen. Dies entspricht
dem Grundsatz der Effektivität von Visualisierungen (vgl. [Schu 00/1]).
Aufgrund der Beschränkung des maximalen Umfangs der Dokumentation sind hier nur die
wichtigsten Aspekte zu finden. Weitere Informationen liefert jedoch die Dokumentation des
Quellcodes.
Als mögliche Anwendung habe ich beispielsweise den Tag der offenen Türen an der
Fachhochschule Fulda gesehen. Die entwickelte Lösung stellt eine anschauliche, geradezu
spielerische Einführung in die Thematik der Mathematik und Informatik dar, welche Brücken
zwischen verschiedenen Themenbereichen wie Algorithmen, Graphische Datenverarbeitung,
Parallelverarbeitung und den damit verbundenen Netzwerken schlägt.
Es ist denkbar, dass es möglich ist, bei Informatik-Interessierten weiteres Interesse an einem
Studium an der FH Fulda zu wecken.
Timo Götzelmann
Seite: 4
1. Struktur des Programms
LandschaftsFraktalBerechnung
TexturFraktalBerechnung
3DDrahtgitter
erstellen
Datenaufbereitung
Texturen
m ischen und
blenden
TexturEbenen
Laden
Mapping und
Erstellung
Displayliste
4
Him m elsDrahtgitter
berechnen
Him m elsTextur
berechnen
W asserfläche
erstellen
Mapping und
Erstellung
Displayliste
Szene
rendern
Interaktion
Benutzer
Mapping und
Erstellung
Displayliste
W assertextur
laden
1
Verteilung der
Grünflächen
Baum textur
laden
Baum Prim itive
erstellen
Mapping und
Erstellung
Displayliste
TransparenzTextur
erstellen
1
2. Generierung der Fraktale
Die entwickelte Lösung beschränkt sich auf Mandelbrotmengen und Juliamengen. Auf den
mathematischen Hintergrund will ich an dieser Stelle nicht eingehen, hierzu findet man in jeder
größeren Bibliothek reichhaltig Literatur.
Timo Götzelmann
Seite: 5
Es ist dem Benutzer überlassen, wie er seine Fraktale berechnen lassen will. Entweder auf nur
einem Prozessor oder mittels des Message- Passing- Interface (MPI) auf mehreren Prozessoren
lokal, oder aber auch auf jeweils mehreren Prozessoren auf mehreren Rechnern.
Die Berechnung von Mandelbrotmengen und Juliamengen ist ein massiv paralleles Problem und
daher unter Verwendung des MPI ideal zu verteilen. Die Berechnung erfolgt nach Übergabe der
Parameter und liefert zweidimensionale Daten zurück. Dies geschieht derart, dass der MPIServer das Problem aufbricht in n Teilprobleme, diese in eine Warteschlange einreiht und auf die
m Rechner verteilt.1
Hierbei hält der MPI-Server fest, welcher MPI-Client gerade welches Teilproblem bearbeitet.
Sobald die Anzahl der verbleibenden Teilprobleme kleiner ist als die Anzahl der verbleibenden
Rechner, also nRest < m gilt, schickt der MPI-Server die restlichen Teilprobleme ebenfalls an die
Rechner, die gerade nicht beschäftigt sind. Somit wird gleichzeitig durch einfache Weise eine
Lastverteilung und eine Minimierung der Berechungszeit erreicht.
Client 1
Teildaten
FraktalModul
Client n
Teildaten
FraktalModul
Server
Daten
Ergebnisse
3. Generierung der Fraktallandschaft
Die folgenden Algorithmen sind mitunter sehr rechenaufwändig, jedoch werden diese vorab
ausgeführt
und
beeinflussen
damit
die
Ausführungsgeschwindigkeit
Simulationsphase nicht.
3.1 Umwandlung in ein 3D-Landschaftsmodell
3.1.1 Umwandlung Koordinaten
Timo Götzelmann
während
der
Seite: 6
Die zweidimensionalen Daten werden in ein dreidimensionales Bezugssystem überführt, indem
die x- und y-Koordinaten auf ein regelmäßiges Gitter übertragen werden2 und der jeweilige
Farbwert der einzelnen Bildpunkte als z-Koordinate dient.
Man kann aber nicht von dreidimensionalen Daten sprechen, da die einzelnen Datenfelder im
dreidimensionalen Bezugssystem keinen Wert enthalten, oder bestenfalls einen unären. Ebenso
existiert pro x- beziehungsweise y-Koordinate in jedem Fall höchstens ein z-Wert.
Zwar wird im späteren Verlauf eine Textur auf diese Felder gemappt, sodass man sagen könnte,
diese Felder im dreidimensionalen Bezugssystem enthalten einen Wert, jedoch ist dieser Wert
eindeutig vom z-Wert abhängig.
3.1.2 Wahl der Primitive
3.1.2.1 GL_QUADS vs. GL_QUAD_STRIP
Für den Aufbau der Drahtgitters habe ich den Typ GL_QUAD_STRIP verwendet, da hiermit
Speicherplatz für die Vertices gespart werden kann, welches sich entscheidend auf die
Ausführungsgeschwindigkeit auswirken kann.
Beispiel:
Definiert man das Drahtgitter mittels GL_QUADS, muss man die angrenzenden Eckpunkte der
einzelnen Primitive mit den gleichen Koordinaten versehen. In
diesem Fall wären das die Vertices 2 und 4 bzw. 3 und 5.
Theoretisch dürfte keine Lücke zwischen den beiden Primitiven
existieren. Jedoch ist es implementierungsabhängig, ob dies auch
praktisch der Fall ist.3
Abbildung 1
Bei GL_QUAD_STRIP entstehen prinzipiell keine Lücken zwischen zwei aufeinander folgenden
Primitiven. Dieser Datentyp vermindert die Anzahl der
definierten Vertices (siehe hierzu auch 2.1.2.1) und spart damit
Speicherplatz. Dieser Speicherplatz wirkt sich ebenso auf die
Ausführungsgeschwindigkeit aus, da weniger Daten im Speicher
verschoben werden müssen. Da wir aber ein zweidimensionales
Drahtgitter verwenden, werden doch noch Lücken zwischen den
1
wobei gilt n ≥ m .
d.h. es gilt R → R
3
beispielsweise durch einen ungenauen Tiefenpuffer oder Rundungsfehler.
2
2
3
Timo Götzelmann
Abbildung 2
Seite: 7
einzelnen Zeilen der aneinander gefügten Quadrate auftreten, allerdings gelingt es uns mittels
dieser Technik, die Anzahl der möglichen Lücken auf die Hälfte zu reduzieren, indem wir Zeilen
von Quadraten erzeugen.
3.1.2.2 Betrachtung der Speicher-Komplexität:
Definiert man einen Streifen (x=2; Ausweitung in eine Dimension y) wie in unserem Beispiel, so
muss man also y-1 Quadrate definieren, d.h. 4(y-1) Vertices.
Ohne Verbindung der einzelnen Vertices an den Ecken der Quadrate (also mittels
 y
 y
GL_QUAD_STRIP) sind lediglich   Quadrate nötig und damit 4  Vertices. Demnach
2
2
wären also bei einer Ausdehnung in eine Richtung bei großen y nahezu die doppelte Anzahl
Vertices notwendig.
Genauer:




 fVerticesMitVerbinden ( y ) 
4( y − 1) 



lim 
= 2.
 = lim
y →∞ f
 VerticesMitVerbinden ( y )  y →∞ 4  y  
   
 2 
Ferner muss man bei einem Drahtgitter mit Ausdehnung in eine Dimension x, wie auch in eine
Dimension y folglich (x-1 )(y-1 ) Quadrate und somit 4(x-1 )(y-1 ) Vertices definieren.
Wäre die Möglichkeit gegeben, dieses Verbinden der Polygone, wie es bei GL_QUAD_STRIP
der Fall ist, in eine Dimension x, wie auch in eine Dimension y anzuwenden, wären lediglich
 x  y 
 x  y 
 2   2  Quadrate notwendig und damit 4 2   2  Vertices. Demnach würde dies bei groß
gewählten x und y eine Ersparnis von beinahe Faktor 4 für die Anzahl der benötigten Vertices
darstellen.
Genauer:




 gVerticesOhneVerbinden ( x, y ) 
4( x − 1)( y − 1) 

 = lim
= 4.
lim 
x , y →∞  g
 VerticesMitVerbinden ( x, y )  x , y →∞ 4  x   y  
    
  2  2  
Wäre es also möglich einen Primitiven-Typ mit zwei nebeneinander liegenden Strip-Flächen zu
entwickeln1, könnte man noch einmal das Doppelte an Speicherbedarf gegenüber den
1
beispielsweise mit der Bezeichnung GL_QUAD_DOUBLE_STRIP oder GL_TRIANGLE_DOUBLE_STRIP.
Timo Götzelmann
Seite: 8
Primitiven-Typen mit einer Strip-Fläche einsparen. Diese Typen wären ideal, Drahtgitter zu
definieren.
3.1.2.3 Kritische Betrachtung
Bei Verwendung eines Dreiecksdrahtgitters - anstatt eines Vierecksdrahtgitters - hätte man zwar
mehr Dreiecke benötigt, jedoch wäre dies eventuell trotzdem schneller, denn heutige 3DBeschleuniger sind auf Dreiecke optimiert, da diese zwangsläufig planar und konvex sind. Dies
ist zwar bei unserer Anwendung mit Vierecken auch der Fall, jedoch könnten diese intern
automatisch in jeweils 2 Dreiecke umgewandelt werden, was zwar sehr schnell hardwareseitig
umgesetzt wird, jedoch dennoch bei extremer Ausreizung der Hardware ins Gewicht fallen kann.
3.2 Logarithmierung
Bei Betrachtung realer Gebirge fällt auf, dass ein nicht linearer Anstieg gegeben ist. Vielmehr
ähnelt die Gebirgskontur einem exponentiellen Anstieg. Zwar verstößt diese und die folgenden
Operationen gegen das Expressivitätskriterium1, doch tragen eben diese erheblich zur
Effektivität der Visualisierung bei.
3.3 Normalisierung der Daten
Die Höhendaten werden anschließend mit dem Kehrwert des Maximalwertes multipliziert.
D.h. für alle Höhenwerte gilt:
v′x , y = v x , y *
1
vmax

wobei : vmax = max v x0 ,y0 ,


 x0 = 1,s x 
.


1
y
,s
=
0
y


Dadurch ist sichergestellt, dass eine maximale Höhe der Gebirgsformationen nie überschritten
werden kann.
Somit besteht keine Beschränkung mehr für die Eingabedaten, weitere Arten von Ausgangsdaten
und damit weitere Anwendungen der Graphikengine sind denkbar2.
3.4 Glättung der Fraktallandschaft
1
2
Siehe auch Vorwort.
Sofern die Darstellung von Daten als 3D-Landschaft Sinn macht.
Timo Götzelmann
Seite: 9
Die Punkte des Drahtgitters enthalten noch sehr sprunghafte Werte, sodass dies nicht sehr viel
Ähnlichkeit mit realen Landschaften aufweist. Reale Landschaften sind Verwitterungsprozessen
ausgesetzt, welche durch 2 verschiedene Algorithmen zur Kantenglättung nachgebildet werden.
Diese erzielen je nach Beschaffenheit der Landschaft mehr oder weniger realistische Ergebnisse.
Einige
weitere
Verfahren
zur
Glättung
der
Landschaft,
beispielsweise
mittels
Fouriertransformation bzw. Binominalfiltern, sind unter anderem in [Leh 97] und [Jäh 02]
beschrieben.
3.4.1 Mittelungsfilter
Der Mittelungsfilter glättet die einzelnen Höhenwerte, indem er den Mittelwert der benachbarten
Höhenwerte anteilig (oder nach Gewichtung) mit dem aktuellen Höhenwert verrechnet.
Für einen Filter, der sx*sy benachbarte Höhenwerte verrechnen soll, ist genauso eine sx*sy
Gewichtungsmatrix notwendig. Im Fraktalexplorer wird eine 3*3 Matrix wie folgt verwendet:
 1 1 1


1 1 1.
1 1 1


Abbildung 3
Die Berechnung der einzelnen Höhenwerte erfolgt im allgemeinen Fall ( s x , s y ∈ Ζ ):
 G sx −1 s y −1 L G s y −1 L G sx −1 s y −1 
 x− 2 , y − 2

, y−
x, y−
x+
2
2
2


M
M
M




L
L
G
G
G
s
x
y
s
−
−
,
1
1
Gewichtungsmatrix:
x− x , y
x+ x , y


2
2


M
M
M


 G x − sx −1, y + s y −1 L G x , y + s y −1 L G x + sx −1, y + s y −1 
2
2
2
2
2 

Formel:
wobei Summe der Gewichte:
v′x , y =
1
∑ Gs x , s y
∑ Gs x , s y =
s y −1
s x −1
2
2
∑
∑v
x + x0 , y + y0
s −1
s −1
x0 = − x y0 = − y
2
2
s x −1
2
∑
s y −1
2
∑G
s −1
s y −1
x0 = − x
y0 = −
2
2
x0 , y 0
Timo Götzelmann
.
G x0 , y0
Seite: 10
Für unseren konkreten Fall einer 3*3-Mittelungsmatrix wie in Abbildung 3 gilt der Sonderfall,
dass sämtliche Gewichte = 0 betragen, so dass man sagen kann Gx , y = 1 :
Summe der Gewichte:
∑ G3,3 =
1
1
∑ ∑ 1 = 9.
x0 = −1 y0 = −1
somit gilt für jeden der Höhenwerte:
v′x , y
=
1 1 1
∑ ∑ vx+ x , y+ y
9 x 0 = −1 y 0 = − 1 0 0
=
1
∑ (vx−1, y −1 , vx, y −1 , vx+1, y , vx−1, y −1 , vx, y , vx+1, y , vx−1, y +1 , vx, y +1 , vx+1, y +1 ).
9
Die Wahl der geeigneten Gewichtungsmatrix kann das Ergebnis maßgeblich beeinflussen, so
kann man auch durch eine geeignete Wahl der Werte der Matrix den gegenteiligen Effekt, eine
Schärfung der Konturen des Höhenfeldes, erreichen. Genaueres dazu in [Burdick 97], eine
Erklärung an dieser Stelle würde den Rahmen dieser Arbeit sprengen.
3.4.2 Medianfilter
Eine weitere Filtertechnik erschien für den Fraktalexplorer interessant zu sein, weil sie die
(Berg-) Spitzen der Höhenkarte nicht so gleichmäßig glättet wie der Mittelwert-Algorithmus.
Ebenso wird die Fraktallandschaft hiermit „sanfter“ geglättet, d.h. sehr große Schwankungen der
Höhenwerte beeinflussen nicht die Landschaft. Der Medianfilter behält durch die Wahl der
mittleren Werte in einem bestimmten Umkreis sx und sy des aktuellen Höhenwertes die Konturen
der ursprünglichen Höhenkarte weitgehend bei.
Somit werden die einzelnen Höhenwerte v jeweils wie folgt berechnet ( s x , s y ∈ Ζ ):

sx − 1
sx − 1 


 x0 = x − 2 , x + 2 
~

v′x , y = X v x0 , y0 , 
sy −1
sy −1 

 y0 = y −
,y+


2
2 


wobei s x = Breite des Filterfensters
s y = Höhe des Filterfensters.
In dieser Anwendung ist dies ein 3*3-Medianfilter, sodass hier gilt ( s x = s y = 3 ):
v′x , y
 x = x − 1, x + 1 
~

= X  v x0 , y0 ,  0

 y0 = y − 1, y + 1

~
= X (v x −1, y −1 , v x , y −1 , v x +1, y , v x −1, y −1 , v x , y , v x +1, y , v x −1, y +1 , v x , y +1 , v x +1, y +1 ).
Timo Götzelmann
Seite: 11
4. Textur-Erzeugung
Als erstes muss die fraktale Landschaft in verschiedene Höhenebenen eingeteilt werden. D.h. es
wird für jedes Quadrat ermittelt, ob es sich dabei um eine Talregion, eine der beiden
Mittelschichten oder eine Gebirgsregion handelt.
Zur Generierung der Gesamttextur werden zufallsweise pro Höhenschicht kleine Texturen
aneinandergereiht. Die 4 Teiltexturen werden aus Dateien ausgelesen und sind somit einfach
auszutauschen. Mehrere Texturstufen wären ohne großen Aufwand machbar, jedoch nicht
unbedingt notwendig.
4.1 Landschaftstextur
4.1.1 Einteilung der Ebenenregionen
Hierzu wird durch eine einfache Histogramm-Funktion gewährleistet, dass die Verteilung der
Texturen gemäß den vorab definierten Anteilen gleichmäßig und damit nicht abhängig ist von
der durchschnittlichen Höhe der Landschaft.
Vorlauf:
a)
Definition der Anteile der einzelnen Texturen Tn, z.B.:
wobei
∑ (T ) = 1.0
T1=0.5
T2=0.25
T3=0.20
T4=0.05
n
b)
Anzahl_Höhenwerte = HöhenlandschaftDimX * HöhenlandschaftDimY
1)
2)
3)
Sammle alle Werte im Feld Höhenlandschaft[][] in Feld Höhenwerte[]
sortiere Feld Höhenwerte[] (beispielsweise mit Quicksort)
Anteiln = 1 − ∑ (Tn )* Anzahl _ Höhenwerte
4)
Grenzwertn = HöhenwerteAnteiln
wobei gilt: für n Texturebenen gibt es (n-1) Grenzwerte
Komplexität des Algorithmus = Kosten der Sortierfunktion, mindestens jedoch O(n)
Timo Götzelmann
Seite: 12
4.1.2 Synthese der Teiltexturen
Hierbei werden den unterschiedlichen Höhenwerten der Fraktallandschaft die zugehörige Textur
(siehe 3.1.1) zugewiesen und somit die Landschaftstextur erzeugt.1
Hierbei wird ein Fehler berechnet, um zwischen den Teiltexturen überzublenden:
foreach y der Landschaftstextur do
foreach x der Landschaftstextur do
if Hoehe[y][x]<grenze1
ebene := 0
fi
else if Hoehe[y][x]<grenze2
ebene := 1
fehler := (Hoehe[y][x] - grenze1) / (grenze2 - grenze1)
fi
else if Hoehe[y][x]<grenze3
ebene := 2
fehler := (Hoehe[y][x] – grenze2) / (grenze3 – grenze2)
fi
else
ebene := 3
fehler := (Hoehe[y][x] – grenze3) / (Hoehemax – grenze3)
esle
Blende Texturen mittels ebene und fehler
od
od
Nun kennzeichnet ebene die zu wählende Textur und fehler den Faktor zur Überblendung von
der Texturebene zur Texturebene-1.
foreach farbe der aktuellen Pixels do
if ebene > 0
TexturPixel = Textur[ebene-1] * (1-fehler) +
Textur[ebene] * fehler
fi
else
TexturPixel = Textur[ebene]
esle
od
Die Zeit- Komplexität des Algorithmus zur Textursynthese beträgt O(n2).
1
Die einzelnen Ebenentexturen werden in einem Feld TexturAnzahlEbenen gehalten.
Timo Götzelmann
Seite: 13
4.1.3 Spannen nicht erlaubt
Durch das Einsparen der Primitive (siehe 2.1.2.1) erliegt man leicht dem Irrglauben, die Textur
nur über die vorhandenen Primitive spannen zu müssen, d.h. wie bei GL_QUADS zu verfahren,
mit dem Unterschied, dass lediglich Lücken zwischen den einzelnen Polygonen bestehen.
Dies führt jedoch zu einer Verzerrung der Textur an den Stellen der Lücken und ist bei unserer
Anwendung natürlich nicht erwünscht.
Beispiel:
Als
Textur
soll
zur
Demonstration
eine
Weltkarte
dienen
und
als
Polygon-Typ
GL_QUAD_STRIP. Um die Anzahl der Polygone zu verringern, versucht man also, die
Koordinaten der Vertices 2 und 4 bzw. 3 und 5 (gemäß Abbildung 2) so zu definieren, dass sie
einen gewissen Abstand haben, sodass man ein komplettes Quadrat (und damit in unserem
Beispiel 4 Vertices) einsparen kann. Wie beschrieben, wirkt sich dies positiv auf die
Ausführungsgeschwindigkeit aus. Verteilt man jedoch die Textur, wie bei GL_QUADS, führt
dies nicht zu dem gewünschten Ergebnis, wie Abbildung 44 zeigt.
Abbildung 4
Man kann hier gut erkennen, dass zwischen den beiden außen liegenden Quadraten eine
Streckung der Textur besteht.
Um also GL_QUAD_STRIP zu verwenden, ist es notwendig, dass man die Texturkoordinaten
definiert, als ob keine Lücken zwischen den definierten Vertices vorhanden wären.
4.2 Himmelstextur:
4.2.1 Generierung mittels Fourierreihe
Hier habe ich eine von [Gard 84] entwickelte Formel benutzt:
Timo Götzelmann
Seite: 14
n
n
i =1
i =1
T ( x, y ) = k ∑ [ci sin ( f i x + pi ) + T0 ]∑ [ci sin (g i y + qi ) + T0 ]
π
 y
sin  g i 
2  2
π  x
qi = sin  f i 
2  2
f i +1 = 2 f i
pi =
wobei :
g i +1 = 2 g i
ci +1 =
2
fi .
2
Hiernach habe ich einen Algorithmus zu Berechnung der Wolkenstruktur geschrieben.
Das dieser jedoch sehr viele Wiederholungen und erkennbare Muster auswies, musste ich einige
Erweiterungen vornehmen, damit bei jedem Start des Programms eine neue Wolkendecke
entsteht.
Gardners Formel habe ich wie folgt erweitert:
[
T ( x, y ) = k ∑ ci sin ( f i * (x + xOff )* zoom + pi ) + T0
n
i =1
wobei gilt :
]∑ [c sin (g * (y + y )* zoom + q ) + T ]
n
i =1
i
i
Off
i
0




(
)
+
y
y
π 
Off 
pi = sin g i * z1*
2 
 1 



 zoom  





(
)
+
x
x
π 
Off 
qi = sin f i * z 2 *
2 
 1 



 zoom  

f i +1 = 2 f i
g i +1 = 2 g i
ci +1 =
2
fi .
2
Wobei für die Parameter gilt:
Der Faktor ci ist zur Steuerung des Kontrastes dienlich. Wir verwenden einen Kontrastfaktor von
0.1 welcher in unserer Anwendung am realistischsten erscheint. Der von Gardner gegebene
Faktor k leistet ähnliches, nur eben auf die Summe der beiden Teilsummen und ist somit als ein
Timo Götzelmann
Seite: 15
Helligkeitsfaktor zu verstehen. Da ci in dieser Anwendung den Wert 1.0 besitzt, könnte er also
einfach entfallen.
Die von Gardner gegebene Variable T0 ist ähnlich wie k für die Helligkeit zuständig, allerdings
als ein Offset. In dieser Anwendung ergab der Wert -0.045 die besten Resultate.
Die Veränderung der Startwerte für f bzw. g streckt bzw. staucht die überlagerten Sinuswellen in
x-Richtung (für f) bzw. y-Richtung (für g). In dieser Anwendung haben beide den Wert 0.07,
welcher sehr realistische Wolken ergab.
Für die Anzahl der Iterationen n habe ich 20 gewählt, da dies einen guten Kompromiss zwischen
Rechenaufwand und Berechnungsqualität darstellt. Zu bemerken ist, dass man bei Änderung der
Anzahl der Iterationen auch die Kontrast- und Helligkeitsfaktoren anpassen muss, damit die
beiden Teilsummen wieder akzeptable Werte ergeben.
Hier wäre bei einer erneuten Erweiterung der Formel eine automatische Steuerung betreffs der
Iterationenzahl gegenüber dem Kontrastwert ci bzw. dem Helligkeitsoffset T0 denkbar. Dies
würde aber den Rahmen dieser Ausarbeitung sprengen.
xOff und yOff haben bei dieser Anwendung Zufallswerte im Bereich von [0..1000]. Sie variieren
den Ausschnitt der Berechnung, um erkennbare Wiederholungen und Muster zu vermeiden.
Ähnlich sind z1 und z2 Zufallsfaktoren im Wertebereich zwischen [0..1] und sichern somit die
Generierung immer neuer Wolkengebilde.
Die Variable zoom definiert, inwieweit in die Berechnung hineingezoomt wird. Große
Zoomfaktoren ergeben weicher verlaufende Wolkentexturen, kleine Zoomfaktoren härtere.
Bei weiterem Interesse zu dieser Formel verweise ich auf den von mir entwickelten „GardnerExplorer“. Dies ist eine von mir entwickelte OpenGL Applikation, mit welcher sich sämtliche
Variablen von Gardners Formel variieren lassen und die direkten Auswirkungen auf das
Ergebnis sofort ersichtlich werden. Auf Anfrage gebe ich gerne dessen Quellcode frei.
4.2.2 Generierung mittels Zufallswerten
Nach Generierung von Zufallswerten erfolgt eine Mehrfachanwendung des so genannten
„Diamond-Square“- Algorithmus um eine Mittelung der Werte herbeizuführen.
Diamond-Square Algorithmus:
Timo Götzelmann
Seite: 16
Dieser ursprünglich von [Mil 86] zur Generierung von fraktalen Landschaften durch
Zufallswerte entwickelte Algorithmus kann ebenso zur Generierung von fraktalen Wolken
angewendet werden. Dieser Algorithmus ist in vielen Bildverarbeitungsprogrammen wie
beispielsweise Photoshop implementiert.
Die Größe der Bitmap hat immer 2n+1 zu sein. Die vier Eckpunkte werden mit Zufallswerten
initialisiert. Hier zur Veranschaulichung in der linken der 5x5 Matrizen.
Anschließend wird der „Diamond“- Schritt ausgeführt (Mitte). Dazu wird der Mittelwert der vier
Punkte errechnet und dieser in das Pixel in der Mitte der vier Punkte geschrieben.
Nun wird im „Square“- Schritt dieser Mittelwert jeweils mit einer Zufallsfunktion verrechnet
und in die Punkte zwischen den vier Eckpunkten geschrieben.
Dieser Schritt wird nun mit reduzierter Kantenlänge für jedes Teilquadrat wiederholt. Hierbei
wird dann auch die fraktale Selbstähnlichkeit ersichtlich.
Dieser Algorithmus kann nicht ohne Scheduling- Algorithmus rekursiv implementiert werden.
Es muss unbedingt Ebene für Ebene iteriert werden, da sonst fehlerhafte Werte berechnet
werden.
Betrachtung der Speicher- Komplexität:
Timo Götzelmann
Seite: 17
Bei einfacher Anwendung des Algorithmus kommt es zu einer Vervierfachung der Vertices:
 fVerticesDiamondSquared ( x, y ) 
 ( 2 x − 1)( 2 y − 1) 
2
lim 
= lim 

=2 .

x , y →∞ 
x
y
→∞
,
xy


 fVerticesUnsquared ( x, y ) 
Allgemein lässt sich also sagen, dass bei n-facher Anwendung dieses Algorithmus bei m
Dimensionen1 eine Speicherkomplexität von O( 2 n*m ) Vertices ergibt.
5. Optimierungen
In diesem Abschnitt sind einige der wichtigsten Optimierungen in Bezug auf Realismus der
Szene und Ausführungsgeschwindigkeit näher erläutert.
5.1 Vernachlässigung der Rückseiten
Zur Geschwindigkeitsoptimierung wird eine Technik namens „Back Face Culling“ angewendet,
welche die Textur lediglich in einer Richtung auf die Primitive mappt. Schließlich ist es bei
dieser Anwendung nicht nötig, auch auf die „Rückseite“ der generierten Landschaft zu blicken.
Die hierfür benutzten Befehle:
- glEnable(GL_CULL_FACE);
Um das Back Face Culling anzuschalten
- glFrontFace(GL_CW);
Um die sichtbare Seite der Textur festzulegen
5.2 Beseitigen des Flackerns
Wegen der Vielzahl von Vertices und dem zeitraubenden Mapping der Textur habe ich mir das
so genannte „Double-Buffering“ zunutze gemacht, um ein Flackern zu vermeiden. Hierzu
werden zwei Puffer verwendet, einer zum Anzeigen der aktuellen Szene und einer zum Zeichnen
der nächsten Szene. Erst wenn das Zeichnen der nächsten Szene abgeschlossen ist, wird diese
auch durch ein Umschalten der beiden Puffer angezeigt.
Timo Götzelmann
Seite: 18
Hierzu benutzte Befehle:
- glutInitDisplayMode(GLUT_DOUBLE) Um die Unterstützung von DoubleBuffering anzuschalten.
- glutSwapBuffers();
Zum Umschalten der beiden Puffer
5.3 Nebeleffekt
Der verwendete Nebel ist exponentieller Nebel und hat zugleich zwei Funktionen. Zum einen
gibt er der Szene mehr Realismus und zum anderen wird er dafür benötigt, um eine Schwäche
des Tiefenpuffers (siehe auch 5.4) auszugleichen.
Für noch mehr Realismus hätte so eine weitere OpenGL Extension, so genannter „Volumetric
Fog“ gesorgt. Dieser ist ab der OpenGL Version 1.3 verfügbar. Man hätte damit Nebel in den
tiefen Regionen der fraktalen Landschaft erzeugen können. Dieses Säumen der Täler mit Nebel
belastet jedoch erheblich die GPU, was nicht im Verhältnis mit der optischen Effekt stand.
5.4 Anpassung der Sichtweite
5.4.1 Maximal mögliche Sichtweite
Mit dem Befehl gluPerspective wird unter anderem die minimale und maximale Sichtweite
eingestellt. Die minimale Sichtweite wählt man sehr klein, damit man möglichst nahe an die
Oberfläche der Landschaft heran fliegen kann. Da die sichtbare Szene je nach Blickpunkt sehr
weitläufig sein kann, muss man normalerweise auch eine große maximale Sichtweite einstellen.
Die maximalen Sichtdistanzen betragen in unserem Fall für x = 12000, y = 12000, z = 350.
In unserem Fall wäre dies der Distanzvektor der Szene:
Distanzmax
= x2 + y 2 + z 2
= 120002 + 120002 + 3502
≈ 16974.
1
In unserem Fall gilt zwar nur m=2, also zwei Dimensionen, jedoch ist es durchaus denkbar, den Algorithmus für
Timo Götzelmann
Seite: 19
5.4.2 Optimierung der Sichtweite
Normalerweise stellt eine wie in 5.4.1 berechnete Sichtweite kein Problem dar. Jedoch enthält
die Szene durch die Verwendung einer Wasseroberfläche mehrere coplanare oder zumindest
nahezu coplanare Polygone im Uferbereich.
Bei großen Differenzen im Viewing-Volumen zwischen dem Near- und Far-Wert kommt es zu
Ungenauigkeiten im Tiefenpuffer von OpenGL, welche besonders in der Ferne zu erheblichen
Rendering-Fehlern führt. Diese Fehler lassen sich auch nicht mit einem Tiefentest auf
GL_LEQUAL oder GL_EQUAL beseitigen.
Es gibt 2 Möglichkeiten, um dieses Problem zu beseitigen:
-
Die Verringerung der Differenz zwischen Distanzmin und Distanzmax
-
Der Gebrauch der Polygon Offset Extension.
Da ich wie in Punkt 5.3 beschrieben, exponentiellen Nebel zum Depth-Cueing einsetze, habe ich
mich für die erste Alternative entschieden, da ab einer bestimmten Distanz der Nebel für das
Auge des Benutzers undurchdringbar dicht ist.
Da ich die Nebelfarbe als reines weiß definiert habe, habe ich auch als Hintergrundfarbe die
Farbe weiß gewählt, damit man keinen Unterschied zwischen Nebel und den Polygonen, die
außerhalb des Viewing-Volumens sind, feststellen kann.
Normalerweise ist es für das menschliche Auge unmöglich, Helligkeitsunterschiede von einem
Prozent zu differenzieren [Schu 00/2]. Allerdings lässt sich dieser Wert sehr von
psychologischen Gesichtspunkten beeinflussen und gilt nur unter optimalen Bedingungen.
Tatsächlich ist bei der von mir entwickelten Anwendung bei einem Helligkeitsunterschied von
10 % zwischen Wolken und weißem Hintergrund mit dem Auge unter Normalbedingungen kein
Unterschied auszumachen.
Dieser exponentielle Nebel entspricht der Formel: e(
− Nebeldichte*Dis tan z )
.
m>2 zu erweitern. Ein Beispiel hierfür wäre die Generierung von dreidimensionalen Wolken.
Timo Götzelmann
Seite: 20
Die Nebeldichte d von 0.00025 sieht in unserer Szene realistisch aus. Wenn man nun fordert, die
Distanz z so zu wählen, dass eine Sichtbarkeit s von höchstens 10 Prozent gegeben ist1, bevor
man nicht mehr zwischen Nebel und weißem Hintergrund unterscheiden kann, kommt man zu
folgender Gleichung:
s
= e(
− d * zmax )
log ( s )
= −d * zmax .
Mit einer Nebeldichte 0.00025 und max. 10% Lichtdurchlass ergibt dies
 10 
ln 
 ≤ −0.00025* z
 100 
−2.30
≤ −0.00025* z
≥ 9210.4.
z
Somit ist bei einem Abstand von 9210 Einheiten tatsächlich kein Unterschied zu dem vorherigen
Abstand von ~16974 Einheiten festzustellen.
Ein positiver Nebeneffekt dieser Optimierung ist die Reduzierung der Anzahl der zu rendernden
Polygone, und der damit verbundene Geschwindigkeitszuwachs.
5.5 Textur- Detailstufen
Ohne die Technik des Bildens so genannter „Mip-Maps“ kommt es unter Umständen bei
Verkleinerungen von Texeln2 (in der Ferne) zu Farbwertsprüngen und Mustern, welche man in
einer Animation als störend empfindet.
Texturen haben unter OpenGL immer 2n Pixel pro Dimension (abgesehen von einem möglichen
Rand von 2 Pixeln). Man berechnet nun also vorab für die Texturen die in Betracht kommen, alle
Detailstufen 2n-1 pro Dimension mit n → 1 . Dabei werden bei jedem Durchgang 2 Pixel zu
einem Pixel durch Mittelwertbildung zusammengefasst.
Zur Laufzeit wird nun also, falls mehrere Texel einem Pixel zugeordnet werden, das MittelwertPixel der jeweiligen Detailstufe benutzt. Durch die Vorberechnung gibt es hier keine
1
2
D.h. dass höchstens 10 % des Restlichts durch den Nebel sichtbar ist.
Pixel einer Textur.
Timo Götzelmann
Seite: 21
Geschwindigkeitseinbußen, jedoch lässt sich zeigen, dass nahezu der doppelte Speicheraufwand
anfällt.
5.6 Texturüberlagerung
Hier habe ich mir eine OpenGL Erweiterung namens „Multitexturing“ (OpenGL Standart 1.1) zu
Nutze gemacht.
Diese erlaubt es, zwei oder mehrere Texturen zu überlagern. Diese Funktion ist in modernen
Graphikkarten hardwaretechnisch unterstützt, womit sich keinerlei Geschwindigkeitsnachteil
ergibt.
Durch diese Technik ist es möglich, die eine Textur über eine Vielzahl von Polygonen zu
spannen (in diesem Falle die vorab berechnete Fraktal-/Landschafts-Textur1), während die
zweite Textur über die Szene gekachelt wird.
Der Vorteil dieser Technik ist, dass bei Vergrößerungen2 eines Texels der Fraktal-/LandschaftsTextur (im Nahbereich) die zweite Textur als Detailtextur wirkt und somit für mehr Realismus
sorgt.
5.7 Bäume
Um die Szene noch mehr an ein Landschaftsbild erinnern zu lassen, habe ich zusätzlich in einer
gewissen Höhenlage Bäume gesetzt.
Die ursprüngliche Textur ist ein normales Bitmap, welches durch ein Programm „Xfrog“ von
Oliver Deussen (siehe [Deussen 97]) erzeugt wurde. Dieses Programm erzeugt fraktale
botanische Gewächse, so genannte „L-Systeme“ sehr realistisch. Diese Datei habe ich derart
modifiziert, dass ich ähnlich wie bei „GIF“-Dateien eine einheitliche Farbe als transparente
Farbe definiert habe und diese dann als normale „BMP“-Datei abgespeichert habe.
Diese Datei habe ich dann mit meinem normalen Bitmap-Lader in ein Feld eingelesen und in
einem zweiten Schritt in ein Feld mit einem Alpha-Wert übertragen.
1
2
Siehe Punkt 4.1.
D.h. mehrere Pixel sind einem Texel zugeordnet.
Timo Götzelmann
Seite: 22
Hierbei habe ich dann unterschieden, ob sich die Farbe um die vorher definierte transparente
Farbe handelt oder nicht, und habe somit eine Textur mit Alpha-Wert erzeugen können.
Mittels der Alpha-Funktion konnte ich damit die Bäume mit Zweigen und Blättern darstellen,
ohne dass sichtbar wurde, dass die Textur eigentliche auf ein Quadrat gespannt wurde, denn dort
wo die Textur als transparent definiert war, war sie auch komplett durchsichtig.
Um zu verhindern, dass die Bäume von der Seite gesehen nicht sichtbar sind, habe ich pro Baum
zwei gekreuzte Quadrate verwendet.
Anmerkung: Die Generierung der Orientierungspfeil-Textur erfolgt nach der gleichen Technik,
nur wird diese zusätzlich mit der Blend-Funktion von OpenGL teiltransparent dargestellt.
Timo Götzelmann
Seite: 23
6. Ausblick und mögliche Erweiterungen:
Es ist im Rahmen dieser Studienarbeit gelungen, den Gedanken der anschaulichen
Visualisierung von Mandelbrotmengen als Fraktallandschaft umzusetzen. Da es aber so gut wie
immer etwas zu verbessern gibt, vorausgesetzt man hat genügend Zeit, will ich einige meiner
Gedanken zu den Verbesserungsmöglichkeiten schildern.
Eine Optimierung, welche man beispielsweise „UnTesselate“ nennen könnte, wäre denkbar. Dies
würde, unter Berücksichtigung eines zulässigen Fehlers die einzelnen Vierecke des Drahtgitters
derart zusammenfassen, dass ein Drahtgitter mit weniger Primitiven entsteht, ohne dass die
Qualität darunter merklich leidet (dazu u.a. [Strot 02/1]). Dies hätte aber einen komplett neuen
Algorithmus zur Erstellung der aneinander gehängten Polygone zur Folge. Eventuell würde es
nicht möglich sein, zusammenhängende Polygone zu definieren, sodass der positive Effekt
aufgehoben werden würde. Eine gute Lösung wäre eine Aufwandsschätzungsfunktion, welche
Fall für Fall entscheidet, welches Verfahren angewendet wird.
Ebenso denkbar wäre eine Kombination mit einer „Level-of-Detail“ Logik, welche einen
weiteren Geschwindigkeitszuwachs zur Folge hätte.
Eine weitere interessante Verbesserung wäre die Entwicklung eines einfachen Algorithmus, der
die Texturen über die Polygone derart verteilt, dass es bei unterschiedlicher Steigung zu keiner
Streckung der Texturen kommt. Dadurch würden die Texturen auf dem regelmäßigen Gitter auch
bei großen Steigungen nicht oder zumindest weniger verzerrt werden, was sich positiv auf den
Realismus auswirken würde.
Da es sich um eine Fraktallandschaft handelt, die zur besseren Optik auch Bäume enthält, wäre
es ideal, wenn auch die Texturen für die Bäume durch Fraktale1 erzeugt würden. Siehe dazu auch
[Strot 02/2] und [Deussen 97].
Es wäre wirklich interessant, all diese Verbesserungen zu verwirklichen, jedoch würden sie bei
Weitem den Rahmen dieser Arbeit in Zeit und Umfang sprengen.
1
so genannte Lindenmayer-Systeme.
Timo Götzelmann
Seite: 24
Es sind durchaus Anwendungen denkbar, in denen die entwickelte Graphikengine ohne größere
Veränderung gleichdimensionale Daten anderer Herkunft ebenso als Landschaft darstellen kann,
vorausgesetzt es macht Sinn, dies zu tun.
Timo Götzelmann
Seite: 25
Quellenverzeichnis:
[Burdick 97]
Howard E. Burdick; Digital Imaging; 1. Edition; Computing McGraw- Hill;
ISBN 0-07-913059-3; 1997; S.140
[Deussen 97]
O. Deussen, B. Lintermann; Erzeugung komplexer botanischer Objekte in der
Computergraphik, Informatik Spektrum 20/4; Springer-Verlag; ISSN 01706012
[Gard 84]
Foley, van Dam, Feiner, Hughes; Computer Graphics: Principles and Practice,
2. Edition; Addison Wesley; ISBN 0-201-12110-7; 1993
[Jäh 02]
Bernd Jähne; Digitale Bildverarbeitung; 5. Auflage; Springer-Verlag; ISBN 3540-41260-3; S. 307
[Leh 97]
T. Lehmann, W. Oberschelp, Erich Pelikan, Rudolf Repges; Bildverarbeitung in
der Medizin; Springer Verlag; ISBN 3-540-61458-3; 1997; S.346
[Mil 86]
Gavin S. P. Miller; The definition and rendering of terrain maps; ACM
SIGGRAPH Computer Graphics; ACM Press New York; ISBN: 0-89791-1962;1986; S. 39-48
[Schu 00/1]
H. Schumann, W. Müller; Visualisierung: Grundlagen und allgemeine
Methoden; Springer Verlag; ISBN 3-540-64944-1; S. 9-13
[Schu 00/2]
H. Schumann, W. Müller; Visualisierung: Grundlagen und allgemeine
Methoden; Springer Verlag; ISBN 3-540-64944-1; S. 85
[Strot 02/1]
T. Strothotte, S. Schlechtweg; Non-realistic Computer Graphics; Morgan
Kaufmann Publishers; ISBN 1-55860-787-0; S.229 – 233
[Strot 02/2]
T. Strothotte, S. Schlechtweg; Non-realistic Computer Graphics; Morgan
Kaufmann Publishers; ISBN 1-55860-787-0; S.321 – 325
Timo Götzelmann
Seite: 26
Anhang
A. Systemvorsetzungen
Getestete Betriebssysteme: - Windows NT
- Windows 2000
- Windows XP
- Solaris Sparc 9.0
- Solaris X86 9.0
- Linux 8.2 / 9.0
Notwendig:
- Graphikkarte
- mindestens 32 MB Speicher
- OpenGL- Unterstützung ab Version 1.1
- Graphiktreiber mit OpenGL Unterstützung als Schnittstelle
- schneller Prozessor (>= 1.5 GHz)
- freier Festplattenspeicher
- Installation 10 MBytes
- zur Laufzeit je nach Auflösung:
- niedrig
4 MBytes
- mittel
16 MBytes
- hoch
64 MBytes
- Maus
Optional:
- bei Mehrprozessorbetrieb:
- MPI – Implementierung für jeweiliges Betriebssystem
- freigegebener Ordner für das Programm
- unter Windows-Systemen:
- Temporär- Verzeichnis „c:\tmp“
Timo Götzelmann
Seite: 27
B. Benutzerdokumentaion
B.1 Grundlegende Interaktionsmöglichkeiten
Die Benutzung der Anwendung ist erdenklich einfach. Mittels der Tasten „+“ bzw. „-„ erhöht
beziehungsweise verringert man die Bewegungsgeschwindigkeit in die Blickrichtung. Man
steuert die „Kamera“ mittels der Maus in die gewünschte Richtung, indem man die linke
Maustaste zur Richtungsänderung gedrückt hält. Eine Kollisionsabfrage verhindert, dass man
sich zu weit von der Szene entfernt, wie auch dass man nicht mit der fraktalen Landschaft
kollidiert oder aber durch sie hindurch „fliegt“.
Für die bessere Orientierung geben zwei Anzeigen über Position und Blickrichtung Auskunft:
Karte
Position (weißer Punkt)
Timo Götzelmann
Richtungspfeil
Seite: 28
B.2 Änderung der Auflösung/ des Anzeigemodus
Mittels der Funktionstasten kann man, soweit vom Computer unterstützt, die Auflösung
verändern, beziehungsweise zwischen Fenster- und Vollbildmodus wechseln.
Funktionstaste:
F1: Vollbild- Modus: 640x480 Pixel
F10: Fenster- Modus: 640x480 Pixel
Achtung:
der Wechsel zwischen den Auflösungen bewirkt erneute Initialisierung der
Szene und somit eine Verzögerung.
B.3 Zusatzoptionen mittels Mausmenü (nur Fenstermodus)
Befindet man sich im Fenster-Modus1 kann man zusätzlich mit der rechten Maustaste eine
Zusatzoption aus dem Mausmenü auswählen.
1
Mausmenüs werden im Vollbildmodus nicht von OpenGL unterstützt.
Timo Götzelmann
Seite: 29
Im Filtermenü kann man sich die Originallandschaft wiederherstellen lassen. Daraufhin kann
man so oft man will testen, wie sich die beiden Filter auf die Landschaft auswirken, oder aber
einfach die zerklüftete Originallandschaft erkunden.
Die Option „Regen“ ermöglicht den Regeneffekt zur Laufzeit an und aus zu stellen.
Wählt man „Drahtgitter“ kann man sich die Landschaft als ein solches anzeigen lassen und somit
etwas über den Aufbau der Szene erfahren.
Beenden lässt sich die Anwendung entweder durch Drücken der Escape-Taste oder durch den
entsprechenden Eintrag im Mausmenü.
Timo Götzelmann
Seite: 30
C. Installation der MPI- Implementierung MPICH 1.2.5 unter Windows NT
1. Herunterladen der aktuellen Version:
http://www-unix.mcs.anl.gov/~ashton/mpich.nt/
2. Installation mit Administrator-Rechten
Beispielsweise unter C:\Programme\MPICH 1.2.5
3. Einrichten der Umgebung
- Ausführen des Konfigurations-Programms
Start -> Programme -> MPICH -> mpd -> MPICH Configuration tool
- Unter Punkt 1. alle Rechnernamen (z.B. CAE01) eintragen.
- Unter Punkt 2. falls notwendig besondere Einstellungen vornehmen .
- Anschließend unter Punkt 2. „APPLY“ Änderungen übernehmen.
- Falls Fehler auftreten:
- Rechnernamen überprüfen.
- Unter Punkt 1. „SELECT“ auswählen und Fehlermeldungen
beachten.
- Jeder Benutzer kann nun unter
[Installations-Verzeichnis]/mpd/bin/ MPIRegister.exe
seinen Benutzernamen und Passwort verschlüsselt in der Registry abspeichern
lassen (Nur notwendig für komfortablere Arbeitsweise mit dem
Kommandozeilen-Programm mpirun.exe).
Timo Götzelmann
Seite: 31
4. Kompilieren von MPI- Programmen unter C
- Folgende Dateien müssen zu den Programmen gebunden werden
wsock32.dll (unter DEV C++ „libwsock32.a“)
mpich.dll ([Installations-Verzeichnis]/SDK/Lib)
Eventuell zusätzlich
mpichd.dll ([Installations-Verzeichnis]/SDK/Lib)
mpe.lib ([Installations-Verzeichnis]/SDK/Lib)
mped.lib ([Installations-Verzeichnis]/SDK/Lib)
- Folgende Include- Dateien müssen im Quellcode eingebunden werden
winsock.h
mpi.h ([Installations-Verzeichnis]/SDK/Include)
- In Windows- Systemen notwendig
Am Programmeinsprungspunkt (main(...)- Routine)
WSADATA wsaData;
if ( WSAStartup(0x101, &wsaData) )
{
printf("Kann leider nicht WinSock- Bibliothek initialisieren.\n");
exit(1);
}
5. Starten des Programms
- mittels MPIRUN.EXE
- von Kommandozeile wie unter Solaris/ Linux
- zusätzliche Optionen:
„ -localonly“ : nur auf lokalem Rechner (bsp. zwei Prozessoren)
„ -logon“
: Erzwingt Eingabe von Benutzer/Passwort
Timo Götzelmann
Seite: 32
- mittels graphischem Tool „guiMPIRun.exe“
- Start -> Programme -> MPICH -> mpd -> MPIRun
oder
[Installations-Verzeichnis]/mpd/bin/ guiMPIRun.exe
- Anwendung auswählen
- Zu benutzende Rechner auswählen
- Anzahl Prozesse auswählen
- eventuell erweiterte Optionen wählen
Beispielsweise: „Always prompt for password“ (wie „ –logon“)
- Starten mit „Run“
- ACHTUNG: die zu startende Datei muss sich in einem Netzlaufwerk
beziehungsweise freigebenen Verzeichnis befinden
6. Besondere Hinweise zum Debuggen
- Falls anhand von Textausgaben debuggt wird, ist es speziell unter Windows
wichtig, den Ausgabepuffer nach einer Textausgabe zu leeren, da sonst unter
Umständen die Ausgabe im Datennirvana endet.
Also: „fflush(stdout)“ nach printf… !
Timo Götzelmann
Seite: 33
D. Quellenangaben für Texturen
Landschaftsebenen:
„Ebene0.bmp“: http://www.the3dstudio.com/(rfktit55lnwger55zfwkpsvr)/textures.asp?id=93
Nachbearbeitet mit Photoshop 7.0
„Ebene1.bmp“: http://www.the3dstudio.com/(rfktit55lnwger55zfwkpsvr)/ textures.asp?ct=Grass
„Ebene2.bmp“: http://www.the3dstudio.com/(rfktit55lnwger55zfwkpsvr)/textures.asp?ct=Stone
„Ebene3.bmp“: http://www.the3dstudio.com/(rfktit55lnwger55zfwkpsvr)/textures.asp?id=182
Detailtextur:
„Detail.bmp“: http://www.the3dstudio.com/(rfktit55lnwger55zfwkpsvr)/textures.asp?id=88
Wasser:
„Wasser.bmp“: http://www.the3dstudio.com/(rfktit55lnwger55zfwkpsvr)/textures.asp?id=275
Baum:
„Baum.bmp“: http://www.xfrogdownloads.com/greenwebNew/gallery/galleryStart.htm
Diese Textur ist mit Photoshop 7.0 erstellt:
- CockpitPfeil.bmp
Sämtliche weiteren Texturen und graphischen Effekte werden eigenständig berechnet.
Timo Götzelmann

Textur Mapping

Transcrição

Documentos relacionados

Profile

FRAKTALE IV

Carl-Bechstein-Gymnasium Erkner

6. August Anstellungseröffnung Andrea Muhheim `vo berg und tal`

Wissenschaftliche Mitarbeiterstelle (TVL-E13 / 75%)

B2_Quali1_H_GermObRoden_05 9

pdf-download

Was Timo werden möchte

Bayerischer Tischtennisverband

Das Hutewald-Projekt im Naturpark Solling-Vogler