Sie sind auf Seite 1von 23

Projektreflektion

By Philipp Mathis

Report zu Workflow und Struktur für Abläufe in der Rendering Pipeline


Inhaltsverzeichnis

1. Einführung
2. Analyse
3. Meilensteine und Projektspakete
4. Literaturverzeichnis

Genre: FPS, Adventure


Core Elements: Shooting, Collecting, Chase
Theme: Steampunk Welt, Sci-Fi
Release: Zürich, 23. Dezember

Steuerung: WASD kann der Spieler sich bewegen, mittels der Maus nach links und rechts
schauen. Durch Drücken der Space Taste kann der Spieler schiessen, jedoch nur in eine
Richtung. Mit etwas Geschick können die Panzer abgeschossen werden.

1. Einführung

Mein Projekt (GPR5300_S1) sollte einen Versuch darstellen, ein Demo Spiel mit eigener
Game Engine zu schreiben, welche zugleich Spielerinput, Gegner Verhalten und
Rendering regelt. Die Demo Reel sollte dabei eine Engine verwenden die gleich das
ganze Spiel implementiert, von Input, Spielverhalten bis zum Renderloop.

Die zur Verfügung gestellte OpenGL Platform ermöglichte mittels der Praktika eine
schrittweise Implementierung aller wesentlichen Aspekte einer Game Engine, angefangen
mit einfachen 3D Objekten wie Würfel und Pyramide, bis zu gerenderten Objekten mit
Reflektionen, Texturen und weiteren Komponenten welche für modernes Rendering
unumgänglich sind. Die Fragestellung welcher ich folgte und die sich im Laufe der Praktika
früh herauskristallisierte, war, wie sich mittels wenig Aufwand die Game Engine in ein Spiel
umbauen lässt, und was für Grundfunktionen ich in der Zeitspanne umsetzen kann.Wichtig
waren mir Gegner welche den Spieler angreifen (idealerweise nicht nur ein Würfel sondern
etwas komplexeres, was ich ja mit dem Gameobjekt Array der Unit.cs Klasse hinkriegte),
eine Spielersteuerung, eine zufällig generierte Spielwelt mit Ziel (Portal), sowie ein paar
Extrafunktionen im Shader wie Nebel, den ich mittels Informationen aus dem Z-Buffer
umsetzen konnte.

Das erstellte Projekt erinnert leicht an die alten 3D Shooter auf Konsolen wie Nintendo 64
und Playstation, mal abgesehen von den Reflektionen welche in vielen Titeln de Fakto
nicht vorhanden sind. Die Absenz einer Kantenglättung oder Anti Aliasing fällt einem schon
ins Auge, besonders der Treppeneffekt (Rasterkonvertierungseffekt, durch die limitierte
Bildauflösung treppenartig erscheinende Kanten und Silhouetten) erinnert mich an die
älteren 3D Titel der 90er an. Wesentlich war für mich eine saubere Umsetzung der Render
Pipeline, was mir bis auf die Transform.cs Klasse gut gelang, sowie interessante
Nebenfunktionen welche mittels der recht rudimentären geometrischen Formen eine
spielbare Welt erstellen sollten. Wäre die Zeitspanne grösser gewesen hätte ich sehr
gerne einen OBJ Loader erstellt, mit dem ich einzelne 3D Modelle einlesen und mit
Materialien versehen als Gameobjekte verwenden könnte. Ich kam dann aber auf die Idee,
die Panzer einfach mit einem Gameobjekt Array zu versehen, und so Turm und Kanone
(ebenfalls aus Würfeln bestehend) mit dem Panzer gemeinsam zu verschieben. Da ich
erst am Ende realisierte wie einfach ich mehrere Texturen Units verwenden kann, war
keine Zeit mehr übrig zweidimensionale Gegner wie in Quake oder Duke Nukem zu
verwenden – mit abwechselnden Texturen für Walkcycle und Angriff, sowie Transparenz.
Ich werde das Projekt auf jeden Fall noch ausbauen, und für mein Portfolio verwenden.
Ebenfalls schade war dass ich viele Funktionen noch in der Program.cs Klasse festlegte,
welche besser in der Game.cs untergebracht worden wären.

Die Schwerpunkte des Spiels bestehen aus Nebel, der im Fragmentshader umgesetzt
wird, einem erweiterten Textur-Konstruktor der es ermöglicht mehrere Texturen in der
Engine zu rendern, einer Kamera Klasse, sowie einer Einheitenklasse, welche die
Generation von Gegnern ermöglicht, welche aus mehreren GameObjects bestehen und
den Spieler angreifen. Die Demo basiert auf meinem eigenen Projekt und nicht auf Philip
Widmann`s Demo. Mittels eines Gameobject Arrays (SceneGraph) wird das Rendern
mehrerer Gameobjekte ermöglicht, und verschiedene Texturen können im Loop (Game.cs)
für verschiedene Gameobjekte dargestellt werden.Die Engine ist dadurch einzigartig, da
sie eigentlich schon die meisten Grundaspekte einer modernen 3D Game Engine umsetzt,
namentlich Input, Spielverhalten und Rendering.

Die ursprüngliche Idee für mein Projekt kam mir durch den 1980 erschienen Titel
Battlezone, einem FPS Arcade Spiel von Atari. Ein Atari-Enthusiast zeigte mir vor ein paar
Jahren dieses Spiel und es hinterliess einen bleibenden Eindruck bei mir. Ebenso wäre ein
Weltraum-Shooter eine interessante Idee gewesen, zum Beispiel ein an dem Railshooter
„Star Wars“ (Atari Inc, 1983) orientiertes Spiel. Auf jeden Fall begann meine Engine mit
dem Praktika, und sobald Drahtgitter-Rendering möglich war, musste ich an den Titel
Battlezone (Atari Inc, 1980) denken. Somit setzte ich in Praktikum P4-P5 ein Spiel um, das
an Battlezone angelehnt ist, mit beweglichen Einheiten (grün) und ein paar Gebäuden,
Sternen und einer Plane als Boden.

Philipp Mathis, battlezone-like (2020)

Das Erstellen der Game Engine machte viel Spass, und war äusserst hilfreich um die
Grundlagen des 3D Renderings zu verstehen, anzuwenden und schliesslich eine Demo
Reel zu schreiben welche viele verschiedene Aspekte einer Game Engine umsetzt. Das
Projekt werde ich auf jeden Fall noch weiter verbessern.
2. Analyse

Das Spiel OpenGL World ist eine kleines Videospiel mit eigener Grafik Engine, in welchem
es darum geht, ein Portal zu finden bevor die gegnerischen Panzer den Spieler daran
hindern. Es wurde mittels den OpenGL Bibliotheken umgesetzt in Csharp, via Microsoft
Visual Studio. Die Gegner können aus der Distanz angreifen und den Spieler
beschädigen, und folgen diesem sobald er in ihre Nähe kommt. Umgesetzt wurde dies mit
einer kleinen State Machine, welche drei verschiedene Zustände kennt. Der Shader
verwendet ein Blinn-Model um Licht und Projektionen in 3D zu simulieren. Ausserdem
besitzt die Spielwelt einen Nebel, damit Gebäude und weit entfernte Objekte übergangslos
aus dem Frustum verschwinden sobald man genug weit entfernt ist.

OpenGL (Open Graphics Library) ist ein Rendering System, basierend auf Rasterisierung.
Als Programmierschnittstelle ermöglicht OpenGL die Darstellung von 2D und 3D Grafiken
in Echtzeit. Die zur Verfügung gestellte Architektur von OpenGL basiert auf dem Windows
„Form“ Format, mit welchem Fenster verwendet werden können welche man
Computergrafiken darstellen kann, zum Beispiel durch DirectX und OpenGL. „Seit dem 31.
Juli 2006 liegt die Weiterentwicklung der OpenGL-API in der Hand der Khronos Group.“
(Wikimedia Foundation Inc, 1992)

Joe Groff, gl1-pipeline-01 (n.d.)

Die OpenGL Schnittstelle operiert in verschiedenen Schritten, welche in der Grafik oben
beschrieben werden; Zuerst brauchen wir die Daten des renderbaren Objektes, in der
Form von Vertex Arrays und weiteren Daten. Danach werden die Objekte
zusammengesetzt als 2Dimensionale Flächen in einem 3D Raum R3. Die Vertex Daten
werden im Vertex Shader zusammengesetzt und weitergegeben an den Fragment Shader,
in welchem jedes Pixel das auf dem Bildschirm erscheinen soll eingefärbt wird; Dabei
können unterschiedliche Modelle verwendet werden um ein Fragment (2D Fläche
innerhalb gewisser Vertices) mit Textur, Licht, Reflektionen und Schatten zu versehen.
Meine ersten Erfahrungen in OpenGL begannen recht früh mit Unity, da es in manchen
Situationen einfach unpassend war einen Linerenderer zu verwenden – ich verwendete
OpenGL also bis zu diesem Punkt lediglich um einzelne Linien im Raum zu ziehen, zum
Beispiel um Pfade anzuzeigen oder sonstige Verbindungen.

Eine Game Engine setzt sich zumeist aus drei Komponenten zusammen; Der Graphics
Engine welche die Szene rendert, der Physics Engine welche zum Beispiel Kollisionen
und Kräfte simuliert, und dem Spieler Input.

Philipp Mathis, Game Engine Diagram (2020)

Prozessoren oder CPU sind programmierbare Rechenwerke die gemäss übergebenen


Befehlen andere Maschinen oder elektrischen Schaltungen steuert und dabei einen
Algorithmus (Prozess) vorantreibt, was meist Datenverarbeitung beinhaltet.
Hauptbestandteile eines Prozessor (kern)s sind das Rechenwerk (insbesondere die
arithmetisch-logische Einheit, ALU) sowie das Steuerwerk (inkl. Addresswerk). Darüber
hinaus enthalten sie meist mehrere Register und einen Speichermanager (engl. Memory
Management Unit, MMU) der den Arbeitsspeicher verwaltet. Zu den zentralen Aufgaben
des Prozessors gehören die Abarbeitung des Maschinenprogramms: arithmetische und
logische Operationen zur Verarbeitung von Daten aus internen oder externen Quellen,
beispielsweise dem Arbeitsspeicher (Wikimedia Foundation Inc, 2020).

Das Hostprogramm welches Steuerung, Distanzberechnungen und das eigentliche Spiel


regelt wird durch den CPU ausgeführt. Ausser dem eigentlichen Rendern von Grafiken
werden also alle Vorgänge innerhalb eines Spieles vom Prozessor übernommen. Um
Grafiken darzustellen, wird der Grafikprozessor von OpenGL direkt angesteuert, zum
Beispiel durch OpenCL/CUDA Code, der durch einen eigenen Compiler eingelesen wird.

Ein Grafikprozessor oder GPU ist ein spezieller Chip, der dazu gedacht ist ein auf die
Berechnung von Grafiken spezialisierter und optimierter Prozessor für Computer,
Spielkonsolen und Smartphones. Zusätzlich gibt er die berechneten Grafiken an ein
Display oder mehrere aus. Früher hatten Grafikkarten gar keine eigenen
Rechenfähigkeiten und waren reine Ausgabekarten (Wikimedia Foundation Inc, 2020).

Ich verwendete meine eigene Pipeline anstatt die zur Verfügung gestellte Engine von P.
Widmann, dadurch hatte ich das Problem, dass schon in der Grundarchitektur das
Program.cs sehr viele Prozesse übernahm, welche eigentlich im Gameloop der Game.cs
hätte verarbeitet werden müssen, spezifisch die Objektkreation, Level Generation und
Kamera-Steuerung. Dafür habe ich meine eigene Engine mit ihren eigenen Vorteilen, mal
abgesehen von einem Problem mit der Rotationsmatrize. Die Objektkreation plante ich
noch im Game.cs niederzuschreiben und aus der Program Klasse zu entfernen, kam
jedoch an einem Punkt nicht weiter und wollte dann keine Zeit mehr verlieren. Dies hätte
den Vorteil dass ich aus anderen Klassen ohne grosse Probleme Objekte generieren und
binden könnte. Die Geometry.cs Klasse hätte sich ebenfalls dazu angeboten, ich hätte
diese aber noch erweitern müssen.

Spieler Input und Rendering werden natürlich in der Game.cs/Supermanager.cs


implementiert, aber das ganze hätte noch sauber in mehrere Funktionen aufgeteilt werden
sollen, namentlich in die Objekt- und Weltkreation. Die Program Klasse wurde dadurch zu
gross und etwas unübersichtlich. Einzelne Probleme bestanden auch in der Architektur der
Transformationsmatrizen, namentlich der Rotations-Matrize. Dies scheint ein Problem der
Transform.cs zu sein und nicht der Camera.cs Klasse, da das selbe Problem der Rotation
auch bei den Objekten (Units.cs) vorkam. Das Hauptproblem bestand in der Vertauschung
der Achsen, also die erste Stelle eines Vector3 (x,y,z) waren vertauscht, denn nur durch
Manipulation der X-Achse der Rotationsmatrix können Objekte um ihre Y-Achse gedreht
werden. Ein Drehen der Panzer auf den Spieler zu, war damit nicht mehr umsetzbar, ist
aber auch nicht weiter tragisch. Bei der Implementation der Schiessfunktion konnte ich
ebenfalls keine passende Drehung einbauen, das bedeutet der Schuss fliegt immer
entlang der Z-Achse in dem Global Space (World Matrix).

Im finalen Shader musste ich aufgrund von Zeitproblemen darauf verzichten die
Lightmatrix voll im Fragmentshader zu implementieren. Aus irgendeinem Grund werden
die Werte nicht richtig übernommen und sind daher teils im Fragment Shader hard
gecodet. Dies könnte aber relativ rasch überarbeitet werden. Die Idee, die Lichtmatrix in
die Kamera Klasse einzubauen war sicherlich gut, aber die Umsetzung bis ins letzte Detail
hätte mehr Zeit gebraucht.. Eine Woche vor der Abgabe konnte ich aus körperlichen
Gründen kaum am Projekt arbeiten, damit verlor ich in den letzten Monaten gut eins bis
zwei Woche Arbeitszeit, welche es ermöglicht hätte, den Fehler der Transform-Klasse zu
finden und korrigieren. Am letzten Tag vor der Abgabe ergab sich noch ein grösseres
Problem, auf einmal konnte die Software die SDL2.dll nicht mehr finden.

Dies lies sich nur dadurch lösen, indem ich eine ältere Version des Projektes hernahm,
und die relevanten Dateien darin durch die aktuelle Version ersetzte. Auch das war schwer
umzusetzen in der Zeit die ich dann noch hatte. Dieses Problem ergab sich jedoch nicht
aus der Transform Klasse, sondern die Anwendung fand die für OpenGL unumgängliche
SDL nicht mehr. Wie ich bei der Abgabe kommentierte, „Leider bekam ich recht unerwartet
noch ein sonderbares Problem in welchem die sdl2.dll nicht aufzufinden war; Stellte sich heraus
das ich unabsichtlich die Verweisstruktur etwas aufgemischt hatte (weiss nicht genau wie) aber ich
musste dann einfach noch probieren alle möglichen älteren Projekte herzunehmen, um das neue
Projekt wieder herzustellen. Brauchte aber seine Zeit, bis zirka 2.23 (Uhr)“.

Wäre das Problem mit der Rotationsmatrize gelöst, könnte man recht einfach eine
Rotation der Gegner einführen, welche sich mittels Interpolation langsam auf den Spieler
zu bewegen bis sie in Reichweite wären, um zu schiessen. Auch die Türme könnten sich
dann rotieren. Ferner wäre nicht nur eine bessere Schussfunktion mit angepasster
Rotation möglich, sondern die Panzer könnten auch Projektile schiessen. Alternativ hätte
man die Schüsse auch mittels Line Rendering auch als eine Art Laser verwenden können.
Dies wäre einfacher gewesen, da im Fall der gegnerischen Attacke der eine Vertex der
Line von der Panzerkanone ausgehen würde, und der zweite auf die Kamera Position
abzielt, und damit eine Art Strahl generiert, der Entweder eine APDS Kanone oder einen
Laser darstellen könnte.

3. Meilensteine und Projektpakete

Ab dem Praktikum P4 begann meine Arbeit an dem Demo Spiel, indem ich nebst einem
grünen Würfel noch eine simple WASD-Steuerung einbaute. Es folgte danach eine stetige
Zunahme an erweiterten Funktionen, wie sich bewegende Gegner, Kamera Drehung, und
ein Random Generator welcher verschieden grosse texturierte Würfel generiert welche
Gebäude darstellen sollen. Der erste Schritt zu meinem Projekt war also die Steuerung
der Viewmatrix, zur Zeit der Abgabe des Praktikums Nummer 4.

// Hook to the escape press event using the OpenGL.UI class library
Input.Subscribe((char)Keys.Escape, Window.OnClose);
Event evt = new Event(new
OpenGL.Platform.Event.KeyEvent(OnKeyStateChanged));
Window.OnMouseMoveCallbacks.Add(OnMouseMove);

//move
Input.Subscribe((char)Key.W, evt);
Input.Subscribe((char)Key.S, evt);
Input.Subscribe((char)Key.D, evt);
Input.Subscribe((char)Key.A, evt);

In der Matrix4 GetViewMatrix() der Viewmatrix übergab ich dann zwei Werte um die
Position in der X- und Z-Achse zu verschieben. Später ermöglichte die Erstellung einer
Kamera Klasse, in welcher die View- und Projektions-Matrix transformiert werden, eine
kompaktere und besser umgesetzte Steuerung, und eine leichtere Zugänglichkeit. Ein 3D
Objekt hat mehrere Komponente, welche eingelesen werden um das Objekt grafisch
darzustellen. Mittels der unten angegeben Zeilen wird ein vollständiges Gameobjekt
zurückgegeben.
public static GameObject Cube(int type)
{
//vertex index
var VertexData = CreateVertexData(0);
//create vertex array object
var cube = new VAO(material, VertexData);
GameObject obj = new GameObject("Object", new MeshRenderer(material,
cube));
game.SceneGraph.Add(obj);
return obj;
}

Es wird zuerst ein VBO (Vertex Buffer Objekt) erstellt mittels der CreateVertexData(int
type) Methode, mittels der von OpenGL zur Verfügung stehenden Architektur
(OpenGL.GenericVAO). Dort werden die texturierten Vertices, die UV`s, Farben und
Normalen eingelesen und an das Material (und damit an den Shader) weitergeleitet.

public static IGenericVBO[] CreateVertexData(int type)


{
List<IGenericVBO> vbos = new List<IGenericVBO>();
vbos.Add(new GenericVBO<Vector3>(new VBO<Vector3>(verticesTextured),
"in_position"));//0
vbos.Add(new GenericVBO<Vector2>(new VBO<Vector2>(UVs), "in_texcoords"));
vbos.Add(new GenericVBO<Vector3>(new VBO<Vector3>(colorsTextured),
"in_color"));//1
vbos.Add(new GenericVBO<Vector3>(new VBO<Vector3>(normals), "in_normal"));
vbos.Add(new GenericVBO<uint>(new VBO<uint>(elementTextured,
BufferTarget.ElementArrayBuffer, BufferUsageHint.StaticRead)));

return vbos.ToArray();
}

Danach wird in der Cube (int type) Methode ein Vertex Array Object oder VAO erstellt,
welches das verwendete Material und das VBO zusammen in ein neues Gameobjekt
übergibt. Das neue GameObjekt wird zuletzt noch an den SceneGraph (ein Array aus
GameObjekten) weitergegeben innerhalb der Game.cs Klasse, und dann im Update
gerendert. In der Program.cs binde ich die Textur, welche später auf das Objekt gespannt
wird. Die Textur wird dabei auf das UV mapping projeziert, welches zuvor bei der
Objektkreation generiert wurde, und jeder Normalen der sechs Würfelflächen einen
normalisierten Vektor zuordnet. Um die Textur sich so wiederholen zu lassen, dass man
einen Boden generieren kann, empfiehlt sich die Repeat-Funktion des Texturewrappers,
damit sich eine Textur stets wiederholt. Ein Vektor2 tile übermittelt wieviele male die Textur
auf einer Fläche wiederholt werden sollte.

...
// Bind texture #0
boxTexture = new Texture("textures/panel.jpg", 0);
game.tex1 = boxTexture;
Gl.ActiveTexture(0);
Gl.BindTexture(boxTexture);
Gl.TexParameteri(TextureTarget.Texture2D, TextureParameterName.TextureMagFilter,
TextureParameter.Linear);
Gl.TexParameteri(TextureTarget.Texture2D, TextureParameterName.TextureWrapS,
TextureParameter.Repeat);
Gl.TexParameteri(TextureTarget.Texture2D, TextureParameterName.TextureWrapT,
TextureParameter.Repeat);

„One matrix is used for each transformation. This is (for) each of rotating, translating,
or defining views and projections (they are essentially moving the model to make it
look like we are looking at it from a specific angle).Imagine we want to translate
(move) and rotate our model. We could define this with two matrices, and then we
could pass these two matrices to the vertex shader, to apply them to each vertex in
the model... A simple shader to execute the transforms would look like this:“

attribute vec4 position;


uniform mat4 model, projection, view
void main ()
{
gl_position = projection * view * model * position;
}

„The variable gl_position is a standard name variable which is the position of the
vertex at the end of the transformation, before it is passed through to the next step of
the pipeline.“
(Jose Salvatierra, 2015)

Eigentlich plante ich noch einen anderen Worldgenerator einzusetzen, den ich neu
schrieb, aber dazu fehlte am Ende die Zeit. Dieser wird auf jeden Fall noch eingebaut in
mein Projekt, da ich damit klar definierte abgegrenzte Räume erschaffen kann.
Voraussetzung dafür wäre ein Grid, mit Nodes oder Tiles, welche koordinaten, sowie eine
Boolean (besetzt, frei) sowie eine Integer (Wasser, Boden, Wand) zugewiesen bekommen,
und dann abhängig von der Tile-Grösse verschiedene Gameobjekte für jedes Tile
generiert. Die Idee für das Wasser wäre, dass das Boden-Tile etwas tiefer gesetzt wird,
und darüber ein transparenter Wasserwürfel, der auf der selben Höhe wie der
gewöhnliche Boden anzusiedeln wäre. Die Wände bestünden nachwievor aus den
Würfelgebäuden mit der Steampunk Textur, nur ware lediglich die Y-Skalierung variable,
aber die X- und Z-Skalierung natürlich entsprechend der Tile Grösse. Dieser neuere
Mapgenerator funktioniert mit einer zufälligen Anzahl an Walkern, welche in eine Richtung
laufen, und nach einer gewissen Wahrscheinlichkeit nach jedem Schritt die Richtung
wechseln könnten, sodass am Ende viele begehbare Pfade entstehen, oder bei einer
grossen Anzahl von Walkern grössere natürlich wirkende Räume. Für verschiedene Levels
könnte man für Boden und Wände verschiedene Texturen verwenden, zum Beispiel
Panels, Sand usw.

Philipp Mathis, Worldgenerator (2020)

Der Fragmentshader bot insofern neue Herausforderungen, da ich die Vertexfarben zuerst
in einem zu hellen Farbton einfärbte, und dadurch alles zu blass aussah. Vollständig
gelöst wurde dieses Problem nicht, aber es ist auch fraglich wieviel der hellblaue
Hintergrund etwas dazu beitrug – idealerweise hätte ich eine im Hostprogramm
festgelegte Hintergrundfarbe, welche direkt an den Shader weitergeleitet wird.
Philipp Mathis, Texturen (2020)

Wie in dem Screenshot sehen ist, habe ich hier 3 verschiedene Texturen verwendet; Eine
Steampunk Panel Textur für die Gebäude, eine Aircraft Panel Textur für die Panzer, und
eine Sandtextur für den Boden. Die Sandtextur ist nicht im Projekt, nur die Panzer- und
Gebäude-Textur, doch fügte noch kurz eine dritte Textur hinzu um die Funktion des neuen
Konstruktors darzustellen. Im Wesentlichen veränderte ich den Konstruktor der Textur
Klasse um eine Uint i, mit welcher ich angab welches Texture Target verwendet werden
sollte. Dadurch ist es möglich, verschiedene Texturen für verschiedene Objekte zu
verwenden. Angepasster Texturen-Konstruktor in Texture.cs, siehe unten.

public Texture(string Filename, uint i)


{
if (!File.Exists(Filename))
{
throw new FileNotFoundException(string.Format("The file {0} does not
exist.", Filename));
}

this.Filename = Filename;
switch (new FileInfo(Filename).Extension.ToLower())
{
case ".dds": LoadDDS(Filename);
break;
default: LoadBitmap((Bitmap)Bitmap.FromFile(Filename));
break;
}
Gl.BindTexture(TextureTarget, i);
}

Im Loop der Game Klasse wird abgefragt wie das generierte Objekt heisst, zB „Tank“,
„Turret“, oder „Platform“. Damit wird für das jeweilige Objekt stets die passende Textur
zugewiesen und gerendert. Idealerweise hätte ich die MeshRenderer Klasse so
angepasst, dass die Textur vom Hostprogramm aus weitergegeben wird an den
Meshrenderer, und dieser diese Textur selber zuweist und rendert. Diese Vorgehensweise
wäre sicher schöner als diese Zuweisung im Game Loop durchzuführen. Auch wäre es
besser gewesen noch eine Methode für das Rendern, Gegner Verhalten und Kollisionen
und weiteres zu erstellen, um damit den Gameloop übersichtlicher zu gestalten.

for (int i = 0; i < SceneGraph.Count; i++)


{
//update scene graph
if (SceneGraph[i].Name == "Tank" || SceneGraph[i].Name == "Turret")
{ Gl.BindTexture(TextureTarget.Texture2D, tex2.TextureID); }
else if (SceneGraph[i].Name == "Platform")
{ Gl.BindTexture(TextureTarget.Texture2D, tex3.TextureID); }
else { Gl.BindTexture(TextureTarget.Texture2D, tex1.TextureID); }

SceneGraph[i].Update();

//sine
float q = 3;
//float s = (1 + (float)Math.Sin(q * Time.TimeSinceStart)) / 2;
FogColor.w = Mathf.Clamp(q * 4,0,1);
}

Die Klasse Camera.cs ist beinhaltet ein Transform, sowie die Lichtmatrix, sowie zwei
Matrizen für die View-Matrix und Projektions-Matrix (V und P). Dadurch kann das
Transform der Kamera verwendet werden, um die Viewmatrix und damit den Spieler im
Globalspace dynamisch zu verschieben. An der Matrix GetViewMatrix und
GetProjectionMatrix selbst ist nichts verändert worden.

//steering for camera

if (game.mouseLook.x < width / 3)


{
game.rotation.x += 0.05f;
}
else if (game.mouseLook.x > 2 * width / 3)
{
game.rotation.x -= 0.05f;
}
//camera pos and rot
if (Camera.Transform.Position.Y > 0.1)
{
Camera.Transform.Position -= new Vector3(0, 0.981f, 0);
}
//camera transform
Camera.Transform.Position = new Vector3(game.movement.x,
game.movement.y, -6 + game.movement.z);
Camera.Transform.Rotation = new Vector3(game.rotation.x, 0, 0);

Der Einfachheit halber habe ich die Rotation und Transformation der Kamera im
Program.cs geschrieben, idealerweise wäre dies aber in der Game.cs umgesetzt worden,
auch weil die Spielerposition in der Game Klasse abgefragt wird, um die Position des
Spielers an die Panzer weiterzugeben, sowie um die Distanz von Spieler und Einheit zu
messen. Die Rotation um die Y-Achse geschieht durch die im Program.cs festgelegte
boolean OnMouseMove, in welcher ein Vektor 2 verändert wird anhand der
Mausbewegungen. Aufgrund des Problems mit der Rotationsmatrize liess ich davon ab
noch eine Rotation um die eigentliche X-Achse einzubauen

private static bool OnMouseMove(int x, int y)


{
if (!OpenGL.UI.UserInterface.OnMouseMove(x, y))
{
game.mouseLook.x = x;
game.mouseLook.y = y;
}
else
{
}
return false;
}

Die Klasse Unit.cs ist eine Erweiterung der GameObject Klasse, und lenkt die
gegnerischen Panzer im Spiel. Um die Panzer etwas interessanter zu gestalten als eine
blosse Box, übergebe ich noch mehrere Objekte an ein Array aus Gameobjekten; einen
Turm und ein Kanonenrohr. Das Gameobjekt der Unit Klasse stellt die Panzerwanne dar.
Im Update werden die Positionen und Rotationen der Bestandteile des Panzers angepasst
so dass diese sich mit der Wanne bewegen. Ursprünglich war vorgesehen, dass ich
lediglich eine Integer an die Einheit übergebe, welche dann in einer Initialize Methode
festlegt welche GameObjekte ich extra kreiiere. Mittels relativ simpler Switch Statements
hätte man so noch recht simpel zum Beispiel einen Buggy, oder ein anderes Fahrzeug
erzeugen können innerhalb der Unit.cs Klasse, indem man verschiedene Cubes dem Unit
Objekt anhängt.

public void Loop()


{
if (alive)
{
//turret and barrel position update
if (turret != null)
{
turret.Transform.Position = this.Transform.Position + new
Vector3(0,0.7,1);
barrel.Transform.Position = turret.Transform.Position + new
Vector3(0, 0, 1);
turret.Transform.Rotation = this.Transform.Rotation;
barrel.Transform.Rotation = this.Transform.Rotation;
}

Target = Camera.Transform.Position;
Target.Z *= -1;
Target.X *= -1;

distance = Vector3.Distance(this.Transform.Position, Target);

//sensors
if (distance < attackDistance) { unitstate = unitState.Attack; }
else if (distance < 40f) { unitstate = unitState.Chase; }
else { unitstate = unitState.Idle; }

//state machine
switch (unitstate)
{
case unitState.Idle:
break;
case unitState.Chase:
Move();
break;
case unitState.Attack:
Attack();
break;
}
}
}
Ein Enum definiert drei verschiedene Zustände der Einheit; Idle, Chase und Attack.
Solange der Spieler sich ausserhalb einer Scanreichweite befindet, bewegt sich die
Einheit nicht. Sobald der Spieler sich ihr nähert, verfolgt sie in bis die Einheit genug nahe
ist um zu schiessen. Dann bleibt diese stehen und greift an, was durch einen pseudo
Kollisionstest vollbracht wird, welcher die Distanz zum Ziel misst, und dem Spieler
kontinuierlich Leben abzieht, sobald der Panzer genug nahe ist. Die Panzer sind mittels
der Schiessfunktion zerstörbar (Space bar), leider schiesst aber diese Methode nur in die
globale Z-Richtung, und kann sich noch nicht der Y-Achsen-Rotation der Kamera
anpassen.

4. Lernprozesse
Interessant war für mich die Betrachtung, wo sich Gelerntes bezüglich Computergrafiken
mit meinen Erfahrungen im Kreativen Bereich überschneidet; Natürlich kannte ich vieles
schon; Matrizen kannte ich nicht nur vom Gymnasium her, sondern auch von meinen
vorherigen Projekten. Vom Verständnis her war aber sehr sinnvoll, dies nochmals im
Unterricht anzuschauen, da ich auch nicht mehr genau wusste, was eine Determinante ist
und es länger nicht mehr rechnerisch anwenden musste. Vektoren waren mir natürlich
ebenfalls bekannt, nochmals das ganze vom mathematischen Standpunkt aus anzusehen
erneuerte nicht nur mein Gedächtnis sondern war auch hilfreich um die Theorie und Praxis
einander näher zu bringen. Natürlich kenne ich mich auch mit der Farbenlehre aus, da ich
selber gerne zeichne und ab und zu male, und das natürlich auch schon schulisch gelernt
habe. Neu ist für mich hier der Zugang zur Mathematik und Software – vieles kannte ich
schon, aber vielleicht von anderen Perspektiven aus. Eine gute Freundin und Künstlerin
hatte zusammen mit einem Maler ein erweitertes (subtraktives) Farbschema
ausgearbeitet, und dies hat sich bei Ihr im Laufe der Jahre zu einer gefestigten Theorie
und Praxis entwickelt. Ich selber hatte es leichter mit dem RGB-Schema und obwohl ich
die Grundidee des subtraktiven Farbenbereiches schon ansatzweise verstehe, ist es in der
Praxis nochmals was ganz anderes.. Man hat nie ausgelernt. Ich gehe davon aus dass, es
ausserhalb von uns keine Farben gibt. Nur Wellenlängen und Werte, also reine
Information.

Für mich persönlich ist auch interessant, wie weit die Maschine immer der Natur
nachempfunden ist; Zum Beispiel Augen und Videokameras verwenden ähnliche
Strukturen um Bilder darzustellen – Shutter, Linsen und eine projektionsfläche sind dem
menschlichen Auge nachempfunden. Dies mag völlig unabsichtlich geschehen, dadurch,
dass die Natur mit ihrer genetischen Intelligenz oftmals die einfachsten und besten
Lösungen für Problemstellungen verwendet; Wir haben keine andere Wahl als von der
Natur abzukupfern; Auch darin steckt der genetische Druck der Natur, Widerstände zu
überwinden.

So viel mir früh auf, dass die drei Ebenen der Programmiersprachen (Maschinencode,
Assembler und Hochsprachen) irgendwie auf gewisse Art und Weise die Architektur des
Nervensystems wiederspiegelt; Auch das Nervensystem hat drei verschiedene Stufen,
jedenfalls nach der „Triune Brain“ These (Paul D. MacLean, 1970). In dieser wird das
menschliche Gehirn in drei Grundarchitekturen aufgeteilt, das „protoreptilische“,
„paläomammalische“ und „neomammalische“ Gehirn. Ein system baut auf dem anderen
auf. Man kann sich fragen wieweit sich also unsere technischen Innovationen im Grunde
immer mit natürlichen Innovationen vergleichbar sind; Das Feld der Biomimetik wendet
Modelle und Systeme an, welche der Natur entspringen, um komplexere menschliche
Probleme zu lösen.

„In this paper, we aim to reveal the similarities between “the structures in nature” and
“man-made structures”. These similarities can be observed from the very beginning of
mankind, in many engineering and architectural designs. It can easily be seen that even
though the scales, functions and processes encountered in nature are different, ‘the
design constraints’ and ‘the objectives’ are the same in what man creates: functionality,
optimization, and cost effectiveness (minimizing material and energy consumption). Thus,
structures in nature exhibiting great lightness and yet rigidity with forms having capacity to
endure internal and external forces in an optimum way are always a source of inspiration
for many progressive architects and engineers.“ (Arslan & A. G. Sorguc, 2004)

Was Arslan und Sorguc im Bereich der Architektur erkannten, lässt sich problemlos auf
Computer und Software übertragen. Die verschiedenen Funktionen einer Spielewelt sind
immer auf unsere menschlichen Sinne ausgerichtet, und ähneln diesen in gewisser Weise.
Insbesondere die Ähnlichkeit des Gesichtssinnes mit dem Vorgang einer Rendering
Pipeline interessiert mich; Die Modelmatrix wäre die wahrgenommene Welt, die
Viewmatrix stellt den Sehsinn dar, und die Projektionsmatrix das Gesichtsfeld. Auch hier
haben wir einen Vorgang, der ein Bild im Geiste generiert, und aus Informationen aus den
sensorischen Nerven ein Bild aufbaut. Dieser Vorgang hat seine Macken, so dass zum
Beispiel der blinde Fleck keine Sinneszellen aufweist, und dadurch das Gehirn das Bild
dort interpoliert. Wenn man den blinden Fleck zum Beispiel auf eine komplexe Struktur
ausrichtet, kann es sein dass man eine Art Glitch wahrnimmt, oder das Gehirn Textstellen
durch eine leere Stelle ersetzt die dem Hintergrund entspricht. Die Art wie Qualia (Farben,
Klänge, Gerüche, Geschmäcker und Beührungen registriert und dargestellt werden ist
sehr unterschiedlich, und von Mensch zu Mensch verschieden. Dies wirft die Frage auf
was es ist, das wir wahrnehmen. Was also existiert ausserhalb der natürlichen Simulation
des Gehirns?

„This thing, what is it in itself, in its own constitution? What is its substance and material?“
Marcus Aurelius, Meditations

Dieser alchemistische Kupferstich zeigt einen Forschenden mit Brille, Stock und Lampe, welcher den
Fussspuren der Natur nachfolgend, ein Sinnbild der Wissenschaften darstellt (Matthäus Merian, n.d.)

Interessant hier ist für mich immer die Schnittstelle zwischen der Inneren und Äusseren
Welt, in dem Falle die konativen (motorischen) und kognitiven (sensorischen) Sinne, denn
verschiedene Sinne funktionieren auf unterschiedlichen Stufen des Gehirns; Die zwei
archaischeren Sinne, der gustatorische und olfaktorische, funktionieren auf der Ebene des
R-Komplexes, also der ältesten Struktur des Gehirns, während der Gesichtssinn zwar
durch das Mittelhirn verläuft, aber die Verarbeitung und Prozessierung der Sinnesreize
grösstenteils sich im Grosshirn abspielt, spezifisch in der okzipetalen Rinde, der visuellen
Assoziationsrinde und dem vorderen Stirnlappen. Somit sind also gewisse Sinne tiefer mit
Instinkt, und damit auch mit der genetischen Intelligenz gekopplt, wobei der Gesichts- und
Gehörsinn evolutionsbiologisch gesehen viel jünger sind und erst in den oberen 2 Stufen
der Gehirnarchitektur immer komplexere Formen annehmen (Wir lassen mal Weich- und
Kerbtiere hier aus der Debatte), dafür aber auch viel komplexere Funktionen übernehmen
können. Die Tatsache dass die 2 ältesten Sinne auch am ehesten mit der genetischen
Intelligez, den Trieben und Instinkten verbunden ist, erklärt sich auch durch deren
Aufnahme von Pheromonen und anderen Botenstoffen via Chemorezeptoren.

OpenGL hatte ich in Unity bis jetzt nur für GL.LINES benötigt in meinen vorherigen
Projekten, und war mir nur teils bewusst dass man damit selber eine Engine aufsetzen
kann. Meine damalige Verwendung von OpenGL bezog sich also strikt auf Linien, zum
Beispiel um Pfade von Einheiten darzustellen, oder dort wo es generell vorteilhaft war,
nicht den von Unity bereitgestellten Linerenderer zu verwenden. Besonders interessant
wurde es für mich mit den Vektorgrafiken, die ab Projekt P4 möglich wurden,
herumzuspielen. Ich selber hatte ja die Atari Zeit nicht erlebt, holte dies aber später nach
durch einen Enthusiasten, und somit Klang bei mir sehr viel an, als ich mittels OpenGL 3D
Objekte rendern konnte. Manchmal haben abstrakte Formen, sehr viel Möglichkeit etwas
auszudrücken, ganz ohne Details und Schmutz, so zum Beispiel Drahtgitter-Grafiken, wie
es zu Beginn der 3D Darstellung verwendet wurde.

Shader hatte ich schon zuvor für Unity geschrieben, jedoch aus eigenem Antrieb und ohne
genaueres Verständniss von Vertex- und Fragmentshader. Dies war zu einer Zeit bevor
der PBR Shader herauskam, ich verwendete also eine Specular Map, sowie einen Rim-
Effekt, und eine Art Maske, mit welcher ich verschiedene Texturen über den Albedo Kanel
legen konnte. Es war ein Versuch einen möglichst interessanten Shader zu schreiben der
mehr Funktionen aufweist als ein Bumped Specular Shader (von Unities Legacy Shader
Bibliothek). Die Reflektionsmodelle nach Lambert, Phong und Blinn waren mir schon ein
Begriff aus meiner Arbeit mit Autodesk Maya, und Softimage XSI. Selber geschrieben
hatte ich diese aber nie, das war ebenfalls eindrücklich einfach da ich diese schon so
häufig verwendete. Ebenso schrieb ich einen Planetenshader, mit welchem ich für ein
virtuelles Planetarium einen Shader für Perturbationen in Planetenatmosphären
programmierte, insbesondere für Gasplaneten. Jetzt verstehe ich sehr viel genauer wie
und was ein Shader ist, was es mir einfacher macht in Zukunft selber bessere Shader zu
schreiben.

Philipp Mathis, jovian clouds (2017)

Die Sinne sind unsere Schnittstelle zu der Welt, dem Aussen, und dem Anderen. Sie sind
trotz ihrer Limitierung in der Lage uns Informationen zuzuführen, welche durch die
assoziativen Rinden sowie andere Anteile des Gehirns in ein dreidimensionales Bild
verarbeitet werden. Ich finde diesen Prozess sehr interessant, da ja eigentlich das
aufgenommene nur pure information ist, und erst die Qualia des Bewusstseins dies alles
einfärben und formen, und gewissen Reizen einen Wert, eine Qualität zuordnen. Wir sind
die Farben, alles andere hat keine Farbe.
Interessant fand ich von demher auch die Art, wie bei einer Renderpipeline die Model-,
View- und Projektionsmatrix ebenfalls für mich eine gewisse Parallele hat mit dem Gehirn
und den Sinnen. Die Assoziationsrinden wären dann der Buffer, und das eigentliche Bild
entsteht im Geist. Genauso wie es bei einer Pipeline glitchen kann, so hat auch das
Gesichtsfeld, und der Sehsinn, seine glitches, zum Beispiel wenn man mittels der
Peripherie des Gesichtsfeldes eine Bewegung erkennt, und das Gehirn nicht genau weiss
was es für ein Bild einsetzen soll; Genau dort zeigt sich dann, dass das ganze schon
irgendwie auch so ein Renderkasten im Kopf ist. „Modern functionalists/computationalists
generally follow Socrates: consciousness emerges from complexity in the brain’s neural
networks.“ (Stuart Hameroff, 2015) Dort liegen noch die letzten Rätsel der
Bewusstseinsforschung, und damit auch der Zukunft, denn ich denke mir dass wir erst
wirklich weiterkommen, wenn sich die Neurophysik gegenüber der Neurochemie
durchsetzt, und der Funktionalismus ersetzt wird.

Dazu besonders interessante Betrachtungen von Roger Penrose [The emperors new
mind]. Penrose geht davon aus, dass die komputationalen Prozesse allesamt unbewusst
stattfinden, und dass Bewusstsein kein solcher Vorgang sein kann, sondern eine in den
Mikrotubulii generierte Kohärenz, welche mittels Dekohärenz in einen Output (Zustand)
kollabiert. “The Penrose–Hameroff model (orchestrated objective reduction: ‘Orch OR’)
suggests that quantum superposition and a form of quantum computation occur in
microtubules—cylindrical protein lattices of the cell cytoskeleton within the brain’s
neurons... In the Orch OR proposal, reduction of microtubule quantum superposition to
classical output states occurs by an objective factor—Roger Penrose’s quantum gravity
threshold stemming from instability in Planck-scale separations (superpositions) in
spacetime geometry. Output states following Penrose’s objective reduction are neither
totally deterministic nor random, but influenced by a non-computable factor ingrained in
fundamental spacetime... In Orch OR, preconscious processing is equivalent to the
quantum superposition phase of quantum computation. “ (Stuart Hameroff, 2015)

„In a pan-psychist view consistent with modern physics, Planck-scale spin networks
encode protoconscious (‘fundamental’) experience (qualia) as well as Platonic values.
Particular configurations of quantum spin geometry convey particular varieties of
protoconscious experience, meaning and aesthetics. The proposed Orch OR events occur
in the brain, extending downward to processes in an experiential Planck-scale medium.
The basic idea is that consciousness involves brain activities coupled to self-organizing
ripples in fundamental reality.“ (Stuart Hameroff, 2015)

(Stuart Hameroff, Superpositions, 2015)


Es ist sicherlich noch unklar, wie makroskopische Quantenzustände wie Superpositionen
sich aufrechterhalten können in so komplexen System, da zum Beispiel bei den kleinsten
Schwankungen eine Superposition dekohäriert einen bestimmten Zustand oder Output
annehmen muss. „Macroscopic quantum states in brain microtubules would have to
somehow avoid environmental decoherence and still communicate with the environment.
Nature may have solved this problem with alternating phases of isolation and
communication.“ []

Genau wie Penrose glaube ich nicht daran das Bewusstsein eine Frage der richtigen
Programmiersprache ist. Wie dem auch sei, ich sehe meine Annahme bestätigt, dass
Innovation stets der Natur folgt, and damit auch natürlich ist, wenn auch nicht organisch.
Zu Kybernetik habe ich allerdings eine ganz andere Haltung. Ich mag es wenn ich die
Schnittstelle in meiner Hand halten kann.. Die blosse Vorstellung, die digitale Schnittstelle
wäre intrusiv in meinem Körper, klingt für mich als Tantriker nach der schlimmsten
existentialistischen Hölle die man sich ausdenken kann.. Vielen fehlt da das
Geschichtliche Verständniss, Vorstellungskraft und der Bezug. Denn Technologie kann ein
Segen sein, oder auch Giftspritze, sie kann Freiheit sein, oder geistiges Gefängnis. Da
hab ich einfach null Interesse an der ganzen VR-Entwicklung, aber ein dumpfes Gefühl in
der Bauchregion welches mir sagt – „ich will kein Brett vor dem Kopf“! Zuerst hielten sie
alle ein Brett vor den Kopf, nun will man es sich um den Kopf binden, damit es einem
dauerhaft die Sicht aufs wesentliche versperrt. Am besten baut man sich das Brett direkt in
den vorderen Stirnlappen ein, dann sieht man am Ende gar nichts mehr ausser Werbung.

Ich empfinde es auch als schwierig, wie wenig Leute sich iheutzutage ernsthaft mit der
Geschichte des letzten Jahrhunderts befassten, und vor allem stets die falschen
Schlussfolgerungen daraus ziehen. Dies wird an den identitären Bewegungen unserer Zeit
sichtbar, auf der Rechten wie Linken Seite des Geplänkels. Es sind nicht die Gruppen,
sondern das Verhalten an und für sich, welches problematisch ist. Hannah Arendt
paraphrasierend lässt sich dieses (meiner Generation oft) fehlende Wissen in einen Satz
kondensieren; das Böse ist banal. Wie drückte es Google 1989 zynisch aus, "Wer nichts
zu verheimlichen hat, braucht eine Beichte nicht zu fürchten.“ Man will sich nicht nur ein
Heiligengewand umhängen, sondern auch noch gleich als Beichtvater und Pfaff ausgeben.
Der neue Klerus einer Technokratie präsentiert sich völlig ungeniert nicht nur als
moralische Instanz, sondern mit der Identifizierung als Technokirche ist der Schritt zur
Ketzerverfolgung nur noch einen Katzensprung weit entfernt. Google paraphrasierte hier
ein Zitat, welches schon die NSDAP in ihren Werbesprüchen verwendete, und etwas
unkritischen Geistern durchaus berechtigt erscheinen mag. Überwachung verhindert keine
Gewalt, dies hat der Beginn des 21ten Jahrhunderts verdeutlicht. Im Gegenteil, diese
kitzelt gezielt die niedrigsten Regungen der Gesellschaft, Wirtschaft und des
Staatswesens hervor.

Lange Rede kurzer Sinn, ich mag Computer, Konsolen und Handhelds viel lieber wie
Mobile Phones, und alles was über die tertiäre Stufe der Kybernetik hinausgeht, kommt
mir nicht in die Wohnung. Ich würde eine altmodische Prothese einer kybernetischen
unbedingt vorziehen, wenn ich eine bräuchte. Dies ist weniger eine reaktionäre Haltung,
als eine Skepsis gegenüber den Intentionen der Megacorporations wie Google, sowie des
Sicherheitswesens an und für sich. Die gesellschaftlichen Reifeprozesse wurden
umgangen, und das Kapital und das Militär kann sich so viele opportunistische Hirne
kaufen wie es will, so dass wir nun alle schon viel mehr bevormundet werden als noch vor
ein paar Dekaden. Die Bevormundung wird herbeigewünscht und beklatscht.
Ob eine Tastatur, eine Kamera, oder ein Mikrophon - alle diese Schnittstellen befinden sich
ausserhalb vom Menschen, und stellen nach meiner Einschätzung keine Bedrohung für
unser langfristiges Überleben dar. Anstatt dass ernsthaft innegehalten wird und man die
aktuelle Lage genauer analysiert, hat die Wirtschaft in unserer Gesellschaft das Recht,
Technologien zu entwickeln welche den Menschen gezielt in seiner Entfaltung behindern.
Die Software Branche streikt generell nicht, sondern setzt zielstrebig das um, was sich
Leute ausgedacht haben, die das alles selber nie bauen könnten. Dabei verlieren wir uns,
da der Bauch nicht über den Kopf herrschen sollte. Der Bauch ist der Motor, nicht die
Steuerung. Wenn der Wirtschaft freien Lauf gestattet wird, alles umzusetzen was Geld
bringt, kann das keine gesunde Entwicklung mehr sein. Man beruft sich dann auf
Marktfreiheit, und dünkt sich Libertär, während man Schritt für Schritt alle zivilen Freiheiten
die unsere Vorfahren sich erkämpften verliert, oder gar freiwillig aufgibt. Ich sehe dies nicht
nur als ein Wirtschaftliches Problem an, sondern ein Mangel an Geschichtsverständnis
und politischer Bildung in der breiten Bevölkerung.

Aber VR ist ja nicht das einzige Gebiet dass wir vertiefen können, mich interessieren als
neue Gebiete Raytracing in Echtzeit, sowie auch die Idee, für ein Spiel evt selber mal in
die Tasten zu hauen und eine kleine kompakte Engine zu bauen. Mit dieser Arbeit als
Fundament sehe ich das durchaus als Möglichkeit, und ich bin total begeistert davon! Ich
begann etwa 1990 Videospiele zu spielen, meine erste Konsole war ein NES, danach
SNES. Mit der Playstation und Nintendo 64, liess ich mich von der 3D Welt verzaubern
und genoss es in diese Welten einzutauchen. Meine ersten 3D Spiele waren Titel wie
Mario Kart 64, Turok, Goldeneye, Quake, Doom und Forsaken. Deswegen hatte ich schon
recht nostalgische Gefühle, als ich dann zum ersten male selber Objekte mit Texturen
rendern konnte per OpenGL, da mich die Grafik dann sehr an gewisse Titel erinnerte.
Spiele mit Vektorgrafik wie Battlezone, also Spiele aus der Zeit des Atari, entdeckte ich
erst viel später für mich.
5. Literaturnachweis

Referenzliste

Atari Inc (1980) Battlezone. [Videospiel, Shoot`em up]. Atari Inc.

Atari Inc (1983) Star Wars. [Videospiel, Railshooter]. Atari Inc

Jose Salvatierra (2015) The OpenGL Pipeline. Verfügbar über: https://opengl-


notes.readthedocs.io/en/latest/topics/intro/opengl-pipeline.html#the-opengl-pipeline
(aufgerufen: Oktober 28, 2020)

Marcus Aurelius (161 bis 180 AD) Meditations.

Stuart Hameroff (2015) Quantum Computation in brain microtubules? The Penrose-


Hameroff „Orch OR“ model of consciousness. Tucson, Arizone: The Royal Society

Wikimedia Foundation Inc (1992) Grafikprozessor. Verfügbar über:


https://de.wikipedia.org/wiki/Grafikprozessor (aufgerufen: Dezember 17, 2020)

Wikimedia Foundation Inc (2020) OpenGL. Verfügbar über:


https://de.wikipedia.org/wiki/OpenGL (aufgerufen: Dezember 14, 2020)

Wikimedia Foundation Inc (2020) Prozessor. Verfügbar über:


https://de.wikipedia.org/wiki/Prozessor (aufgerufen: Dezember 17, 2020)

Wikimedia Foundation Inc (2019) Triune Brain. Verfügbar über:


https://de.wikipedia.org/wiki/Triune_Brain (aufgerufen: Dezember 17, 2020)

Arslan & Sorguc (2004) Similarities between „structures in nature“ and „man-made
structures“: biomimesis in architecture. Verfügbar über:
https://www.witpress.com/Secure/elibrary/papers/DN04/DN04005FU.pdf (aufgerufen:
Dezember 20, 2020)

Bildnachweis

Joe Groff, gl1-pipeline-01 (n.d.) [Online]. Verfügbar über:


http://duriansoftware.com/joe/media/gl1-pipeline-01.png (aufgerufen: Oktober 28, 2020)

Matthäus Merian, Alchemistischer Kupferstich (n.d.)

Philipp Mathis, battlezone-like [selbstgemacht] (hergestellt: Dezember 20, 2020)

Philipp Mathis, Texturen (2020) [selbstgemacht] (hergestellt: Dezember 18, 2020)

Philipp Mathis, Worldgenerator (2020) selbstgemacht] (hergestellt: Dezember 20, 2020)

Philipp Mathis, Titelbild (2020) selbstgemacht] (hergestellt: Dezember 20, 2020)


Philipp Mathis, Jovian Clouds (2020) selbstgemacht] (hergestellt: Spring, 2017)

Stuart Hameroff, Superpositions (2015) [Online] Verfügbar über: (aufgerufen Dezember


12, 2020)

Glossar

Array Eine Anordnung eines bestimmten Datentyps

Blinn Blinn-Phong Reflektionsmodel, ein standart Shading Model in OpenGL

Boolean Ein Datentyp, der zwei verschiedene Zustände kennt, 0 und 1

Compiler Ein Programm welches Computersprachen übersetzt

CPU Siehe Prozessor

C# Siehe Csharp

Csharp Eine moderne Hochsprache unter den Programmiersprachen

Fragmentshader Programm welches vom Grafikprozessor ausgeführt wird

Gameobjekt Klasse welche Objekte darstellt mit verschiedenen Komponenten

GPU Siehe Grafikprozessor

Grafikpipeline beschreibt den Vorgang des Rendern eines Grafiksystems

Grafikprozessor Auf die Berechnung von Grafiken ausgelegter Prozessor

Maschinencode Programmiersprache welche den Prozessor operieren lässt

Matrix Anordnung von Elementen in Reihen und Spalten

Normale Vektor der Orthogonal (rechtwinklig) zu einer Fläche steht

OpenGL Programmierschnittstelle zur Entwicklung von Computergrafiken

Pipeline siehe Grafikpipeline


Prozessor Programmierbares Rechenwerk, die Befehle verarbeitet

Rendering Erzeugung eines Bildes mittels Rohdaten in 2D oder 3D

Textur Grafik welche über ein 3D Objekt gewickelt wird

VBO siehe Vertex Buffer Objekt

Vertex Punkt, Ortsvektor, stellt eine Ecke eines Polygons dar

Vertex Buffer Objekt Lädt Vertexdaten wie Position und Farben auf das Videogerät

Vertexshader Ein Shader welcher in jedem Durchlauf alle Punkte eines 3D


Objektes berechnet und transformiert.

Vektor Mathematisches Objekt, Element eines Vektorraumes

Z-Buffer Stellt die zu zeichnenden Elemente einer Szene dar und


schneidet alle verdeckten Elemente aus