Vorwort. Thomas Lucka. Spiele entwickeln für iphone, ipad und ipod touch ISBN: Weitere Informationen oder Bestellungen unter

Transkript

1 Vorwort Thomas Lucka Spiele entwickeln für iphone, ipad und ipod touch ISBN: Weitere Informationen oder Bestellungen unter sowie im Buchhandel. Carl Hanser Verlag, München

2 Vorwort Ausgerechnet Microsoft bewahrte Apple 1997 mit einer Investition von 150 Millionen Dollar vor dem Zusammenbruch. 13 Jahre später hat sich der Wert der Apple-Aktien mehr als verzehnfacht, und der Software-Riese Microsoft wird erstmals als weltgrößtes Technologieunternehmen (nach Marktwert) abgelöst diesmal von der Firma mit Hauptsitz in Cupertino, Kalifornien. Als Steve Jobs 2007 das Mikrofon auf einer Bühne in San Francisco in die Hand nahm, um ein neues revolutionäres Handy vorzustellen, und behauptete, dessen Technologie sei allen Mitbewerbern um zwei Jahre voraus, konnte man noch nicht ahnen, dass er sich offenbar selbst ein wenig unterschätzt hatte: Auch 2010 gelten iphone, ipod touch und das ipad als Symbole für technologischen Fortschritt. Dabei haben andere Hersteller wie Nokia, Samsung, Sony Ericsson oder Google längst weitaus leistungsfähigere Handhelds auf den Markt gebracht. Mit ein Hauptgrund für die herausragende Stellung Apples liegt daher auch weniger in der Hardware als vielmehr in dem nahtlosen ökonomischen System rund um den App Store, der mittlerweile mehr als Spiele und Programme bereithält und damit als der größte Download-Markt in der Mobilindustrie gilt. Die Grundlage für den App Store legte Apple bereits einige Jahre zuvor mit dem itunes-portal, das durch die Verbindung von Hardware (MP3-Player) und Software (itunes) anderen Musik-Download-Plattformen stets eine Nasenlänge voraus war. Als dann im Sommer 2008 (ein Jahr nach Einführung des iphones) mit dem iphone SDK unabhängigen Entwicklern Zugriff auf die iphone-hardware gegeben wurde, war schnell klar, dass sich hier tatsächlich eine kleine Revolution vollzog: Mit kleinen Apps konnte der Funktionsumfang des nativen Betriebssystems beliebig erweitert werden, und die (damals noch) einzigartige Touch- und Sensorsteuerung erlaubte völlig neue Spielerfahrungen. Nun ist es ja nicht so, dass Apple die Sache mit den Apps erfunden hat, aber das von Apple strikt vorgegebene Zusammenspiel von Entwicklung, Deployment und Distribution ermöglichte jedem noch so kleinen Hobbyentwickler, an den Vorzügen der digitalen Vertriebsform unmittelbar teilzuhaben. Und ja, es ist trotz der unüberschaubaren Anzahl tatsächlich immer noch möglich, mit Spielen im App Store viel Geld zu verdienen. Wenn Sie die in diesem Buch vorgestellten Beispielprogramme nachvollziehen und die Grund- IX

3 Vorwort lagen der Spieleentwicklung in eigene kleinere Spieleprojekte umsetzen, sollten Sie zumindest in Lage sein, den Kaufpreis dieses Buches wieder einzuspielen. Lassen Sie uns also keine Zeit verlieren! Ein Buch wie dieses entsteht nicht im luftleeren Raum, und so möchte ich einigen Personen meinen herzlichen Dank aussprechen: Fernando Schneider, der mit der Idee zu einem iphone-spielebuch an mich herantrat und dabei auf mehr als offene Ohren traf. Holger Patz, ohne den die Spiele in diesem Buch weitaus weniger gut ausgesehen hätten, maßgeblich das 3D-Spiel Spaceflight, die Pixelzombies und der 360-Grad-Shooter im OpenGL ES 2D-Kapitel (für die weniger gelungenen Spielegrafiken bin ich selbst verantwortlich). Janina Sieslack, die sich wie immer fleißig (und oftmals verzweifelt) über die Erstfassungen des Manuskriptes beugte. Markus Maaßen und Juan Pao, ohne deren Begeisterung für Apple-Produkte ich mir 2008 kein MacBook gekauft hätte. Unverzichtbaren Input zum Buch haben beigesteuert: Jörg Büttner, Sandra Gottmann, Bernd Hein, Patrick Hennies, Alexander Hüsgen, Sascha Kolewa, Marco Kraus, Anita Nagy, Julia Stepp, Szymon Ulewicz und Marcus Weidl. Ganz besonders danken möchte ich auch meiner Mutter, die mir bereitwillig den Rücken freigehalten hat, wann immer ich den Weg von Berlin nach Kassel auf mich nahm und das Schreiben der unvermeidlichen Arbeit im elterlichen Garten vorzog. Nun wünsche ich Ihnen aber viel Spaß beim Lesen und natürlich ganz viel Erfolg mit Ihren ersten eigenen Spielen im App Store mit diesem Buch haben Sie den ersten Schritt getan. Happy Coding! (^^)/ St. Peter Ording, im August 2010 Thomas Lucka X

4 Leseprobe Thomas Lucka Spiele entwickeln für iphone, ipad und ipod touch ISBN: Weitere Informationen oder Bestellungen unter sowie im Buchhandel. Carl Hanser Verlag, München

5 5 5 Die dritte Dimension: 3D-Spiele 5.1 Wie sind 3D-Spiele aufgebaut? Der Sprung in die dritte Dimension ist nachdem wir bereits OpenGL ES für 2D-Spiele eingesetzt haben nur ein kleiner Schritt: Wir haben gesehen, dass die Transformationsfunktionen standardmäßig drei Koordinaten (x-y-z) erwarten für 2D-Spiele brauchten wir lediglich die unbenutzte z-koordinate auf 0 zu setzen. Auch die MainView-Klasse, die die Einrichtung des OpenGL ES-Grafikkontextes erledigt und die die drei benötigten Buffer (Renderbuffer, Framebuffer und Depthbuffer) initialisiert, unterstützt bereits die 3D- Darstellung von Modellen. Daher sind für den Sprung in die dritte Dimension nur drei Anpassungen nötig: 1. Umstellung der Perspektive (über setoglprojection) 2. Aktivierung des Tiefenpuffers (z-achse) 3. Modelle müssen über drei statt zwei Koordinaten verfügen (Vertex-Arrays) Das hört sich gar nicht so kompliziert an und ist es auch nicht. Dass 3D-Spiele trotzdem als technisch anspruchsvoll gelten, hat einen anderen Grund: Stellen Sie sich typische Genre-Vertreter vor, wie zum Beispiel einen Ego-Shooter, ein Autorennspiel oder ein Third Person Action Adventure. Wie sind diese Spiele gemacht? Der Spieler findet eine frei begehbare Landschaft vor, die er von den verschiedensten Blickwinkeln betrachten kann. Dazu kommen die darin enthaltenen 3D-Modelle (Autos, Menschen, Monster usw.), die ebenfalls von allen Seiten gut aussehen sollen. Durch die räumliche Ausdehnung der Objekte müssen nicht nur verschiedene Texturen erarbeitet werden, sondern auch deren Formen über hochkomplexe externe Editoren modelliert werden die Erstellung selbst einfacher 3D-Szenen übersteigt damit häufig das zeitliche und finanzielle Budget eines Hobby-Entwicklers. Neben der Modellierung der Szenen und Modelle kommen natürlich noch weitere Hürden hinzu: Die räumliche Darstellung sorgt für mehr Realismus dadurch sollten sich auch die 237

6 5 Die dritte Dimension: 3D-Spiele Bewegungen der Modelle physikalisch möglichst realistisch verhalten. Und vielleicht wollen Sie zusätzlich noch verschiedene Lichtquellen und Materialeigenschaften berücksichtigen. Abb. 5.1: Hero of Sparta (Gameloft), Need For Speed Undercover (Electronic Arts), Mirror's Edge (Electronic Arts) Bevor Sie ein 3D-Spiel planen, sollten Sie sich vorher gut überlegen, was alles auf Sie zukommt und ob Sie diesen Aufwand wirklich allein bewältigen können. Sie haben nicht ewig Zeit: Zwei Jahre und mehr an einem 3D-Spiel im stillen Kämmerlein zu werkeln ist im Hinblick auf den schnelllebigen App Store keine gute Idee: Das Risiko, dass Ihr Spielkonzept längst veraltet ist und/oder technisch mit den neuesten Produktionen großer Studios nicht mithalten kann, sollten Sie nicht unterschätzen. Dennoch das Thema ist andererseits viel zu spannend, um es einfach so zu übergehen. Und Sie werden sehen, die Grundlagen lassen sich immerhin recht schnell erarbeiten. Wir wissen ja bereits, dass für OpenGL ES alles aus Eckpunkten besteht: Ob Sie nun eine Gebirgslandschaft, ein Kellerverlies oder ein Automodell darstellen wollen 3D-Spiele werden aus einzelnen Modellen zusammengesetzt, die wiederum aus zahlreichen Eckpunkten, den Vertices, bestehen. Unabhängig vom Spielkonzept müssen Sie die folgenden Kernaufgaben bewältigen: Erzeugen der Modelle (über eine externe Modellierungssoftware oder auf Basis einfacher geometrischer Grundformen) Positionierung dieser Modelle im Raum Bewegung/Animation der Modelle Kollisionsprüfung der Modelle untereinander Positionierung einer Kamera Wie ließe sich nun ausgehend von diesen Bausteinen ein 3D-Spiel erzeugen? Zwei Anregungen: Beispiel 1: Für ein einfaches Autorennspiel benötigen Sie mindestens eine zweidimensionale Grundfläche (Plane). Auf dieser können Sie den Straßenverlauf mit Texturen darstellen. Wenn Sie die dritte Achse (Höhenverlauf der Strecke) aus pragmatischen Gründen ausklammern, können Sie die Kollision mit dem Straßenverlauf über eine 2D-Tilemap prüfen. Die Rennautos bestehen, ebenso wie Hindernisse oder Häuser am Straßenrand, aus 238

7 5.2 Das Grundgerüst 3D-Modellen, die Sie auf dieser Ebene platzieren und (im Falle der Autos) entlang der Rennstrecke fortbewegen können. Beispiel 2: Ein Doom-Shooter bzw. ein Labyrinth-Spiel: Wieder legen Sie eine zweidimensionale Grundfläche an die Wände bestehen aus mehreren 3D-Quadern, die Sie anhand einer 2D-Tilemap aufstellen. Erhöhte Ebenen oder Stufen werden ausgeschlossen. Ihre Spielfigur bewegt sich auf der 2D-Tilemap, die Kollision erfolgt ebenfalls über die Tilemap, die festlegt, wo die Wände aufgestellt sind. Sie sehen: Auch hier müssen Sie die Kollisionskontrolle nicht zwischen Spieler und senkrechter Wand vornehmen, sondern übertragen lediglich die Konzepte aus der 2D-Spieleentwicklung. Auch für frei bewegliche Spielobjekte (Spieler, Monster, Geschosse) können Sie die Bodenposition vergleichen (2D-Kollision) oftmals kann es unter Umständen aber auch einfacher sein, die Modelle direkt gegeneinander auf Kollision zu prüfen. Sie sehen, auch wenn viele 3D-Spiele auf den ersten Blick sehr eindrucksvoll wirken, verbergen sich mitunter einfache Grundkonzepte dahinter. Auch Spieleentwickler kochen nur mit Wasser. Beginnen wir also zunächst damit, die passenden Lösungen auf die oben benannten Kernaufgaben zu finden. Im Anschluss werden wir anhand der Ergebnisse exemplarisch einen 3D-Weltraum-Shooter entwickeln. 5.2 Das Grundgerüst Zum Erstellen des ersten 3D-Projektes verwenden wir als Basis das Grundgerüst aus dem 2D-Kapitel, das bekanntermaßen aus drei Klassen besteht: MyGameAppDelegate MainView GameManager Sie finden das fertige Projekt im Download-Ordner unter dem Namen "OGL3D_Basics". Um nun die 3D-Perspektive einzurichten und den Tiefenpuffer zu aktivieren, der bereits in der MainView-Klasse erzeugt wurde, müssen wir lediglich die setoglprojection-methode des GameManagers anpassen: - (void) setoglprojection { glloadidentity(); //Set View glmatrixmode(gl_projection); znear = 0.1; zfar = 2500; fieldofviewangle = 45; float top = znear * tan(m_pi * fieldofviewangle / W); float bottom = -top; float left = bottom * W / H; //Seitenverhaeltnis: W / H; 239

8 5 Die dritte Dimension: 3D-Spiele float right = top * W / H; glfrustumf(left, right, bottom, top, znear, zfar); //3D-Perspektive //Enable Modelview: Auf das Rendern von Vertex-Arrays umschalten glmatrixmode(gl_modelview); glenableclientstate(gl_vertex_array); glenable(gl_depth_test); gldepthfunc(gl_less); } Wie bereits beim Einrichten der 2D-Perspektive müssen wir OpenGL ES zuerst in den Matrix-Modus GL_PROJECTION versetzen. Anstelle der glorthof()-funktion kommt nun die glfrustumf()-funktion zum Einsatz, die ansonsten aber die gleichen Parameter erwartet. Über diese Methode legen wir die Perspektive auf das Spielgeschehen fest, nicht jedoch die Kameraposition. Um diese werden wir uns später kümmern. Gleichwohl sorgt auch diese Funktion bereits dafür, dass es eine Kamera gibt nämlich den Betrachter, der auf die Szene blickt: Dieser befindet sich direkt über dem Koordinatenursprung und blickt entlang der negativen z-achse in die Tiefe. Der Blickwinkel beträgt dabei 45 Grad (fieldof- ViewAngle, entspricht einem Kameraobjektiv). Da der Betrachter das Geschehen räumlich wahrnehmen soll, benötigen wir auch eine Tiefenangabe: zfar. Alle Objekte, die sich hinter dieser Grenze befinden, sind nicht zu sehen, ebenso wie Objekte, die sich vor znear befinden. Daher bezeichnet man beide Parameter auch als Clipping Panes. Anhand dieser Parameter kann man die Abmessungen left/right/bottom/top wie in der Implementierung gezeigt berechnen. Abb. 5.2: Frustum mit znear- und zfar-ebene Wenn wir später eine Kamera hinzufügen, werden wir sehen, dass sich znear und zfar relativ zur Kameraposition verändern. Das heißt, der Betrachter wird nie Objekte sehen können, die weiter als 2500 Einheiten (= zfar) entfernt sind. Die Parameter für znear und zfar müssen per Definition stets beide größer als 0 sein. Es ist üblich, znear möglichst klein zu wählen, um den blinden Bereich zwischen Betrachter und znear möglichst schmal 240

9 5.3 Das 3D-Koordinatensystem zu halten und zfar möglichst groß zu wählen aber auch nicht zu groß, da sonst die Performance einbrechen könnte, wenn zu viele Objekte gerendert werden müssen. Zu guter Letzt aktivieren wir in der setoglprojection-methode noch den Tiefenpuffer (GL_DEPTH_TEST), bestimmen die Standard-Alpha-Funktion (GL_LESS) und ermöglichen dauerhaft die Übergabe von Vertex-Arrays über den Client-State GL_VERTEX_ARRAY. Sie kennen dies ja bereits aus dem 2D-Kapitel. 5.3 Das 3D-Koordinatensystem Mit den gezeigten Projektionseinstellungen verfügen wir damit über das folgende Koordinatensystem: Der Koordinatenursprung (Origin) befindet sich in der Screen-Mitte. Die positive x-achse zeigt nach rechts. Die positive y-achse zeigt nach oben. Die positive z-achse zeigt zum Betrachter, die negative z-achse zeigt in den Bildschirm hinein. Abb. 5.3: 3D-Koordinatensystem unter OpenGL ES Es handelt sich dabei um ein "rechtshändiges" kartesisches Koordinatensystem (der Mittelfinger (= z-achse) zeigt zum Betrachter) im Gegensatz beispielsweise zu DirectX: Hier verläuft die positive z-achse entgegengesetzt in den Bildschirm hinein. 241

10 5 Die dritte Dimension: 3D-Spiele Anders als bei einer 2D-Perspektive gibt es keine Einheiten für die Koordinaten. Der Punkt P (10, 30, 20) bezieht sich daher nicht auf Pixelangaben sondern man spricht stattdessen schlicht von "Einheiten". Der Punkt P befindet sich also 10 Einheiten parallel zur x-achse vom Ursprung entfernt, 30 Einheiten parallel zur y-achse vom Ursprung entfernt und 20 Einheiten parallel zur z-achse vom Ursprung entfernt. Der Grund für die Einheiten liegt einfach darin, dass sich aufgrund der Perspektive und der Kameraposition die tatsächliche Pixelposition auf dem Bildschirm erst nach der Projektionsberechnung der Eckpunkte im Framebuffer ergibt. Eine näher beim Betrachter verlaufende Linie erscheint somit länger als eine weiter entfernte Linie der gleichen Länge. 5.4 Einfache Formen zeichnen Mit dem Bild dieses Koordinatensystems im Kopf können wir uns bereits vorstellen, wo sich Objekte befinden müssen, damit sie von uns gesehen werden können. Da wir noch keine Kamera aufgestellt haben, befinden wir uns direkt am Ursprung und blicken die negative z-achse entlang. Ein paar Beispiele: Der Punkt P1 (0, 0, 6) befindet sich vor dem Betrachter, die Entfernung beträgt: -znear-6 Einheiten. Der Punkt liegt damit innerhalb des sichtbaren Bereiches. Der Punkt P2 (0, 0, 60) befindet sich vor dem Betrachter, die Entfernung beträgt: -znear-60 Einheiten. Der Punkt liegt damit innerhalb des sichtbaren Bereiches, ist aber weiter entfernt als der vorherige Punkt P1. Der Punkt P3 (0, 0, 6) liegt dagegen im Rücken des Betrachters und ist nicht sichtbar. Wie auch schon für die 2D-Programmierung erläutert, stehen uns verschiedene Konstanten zur Verfügung, um aus Eckpunkten eine (räumliche) Fläche zu rendern. Wir setzen dabei dieselben Funktionen wie zuvor ein und können auf dieselben Konstanten zurückgreifen (GL_POINTS, GL_LINES, GL_TRIANGLES, usw.). Der Unterschied zu 2D besteht darin, dass wir nun drei Koordinaten pro Eckpunkt angeben können aber nicht müssen. Sehen wir zuerst ein Beispiel, wie wir eine Linie im Raum rendern, die nur aus xy-koordinaten besteht: - (void) drawline { GLbyte vertices[ ] = { 0, 0, //Vertex 1 1, 0 //Vertex 2 }; glpushmatrix(); glcolor4f(1, 1, 0, 1); //Zeichenfarbe setzen glvertexpointer(2, GL_BYTE, 0, vertices); //2 Werte pro Eckpunkt gltranslatef(0, 0, -znear ); gldrawarrays(gl_lines, 0, 2); //2 = Anzahl Eckpunkte 242

11 5.4 Einfache Formen zeichnen glpopmatrix(); } Da wir eine räumliche Perspektive gesetzt haben, wird die z-koordinate automatisch ergänzt und beträgt schlicht 0. Abb. 5.4: Eine gelbe Linie, sonst nichts! Der erste Punkt der Linie befindet sich bei (0, 0), also im Ursprung. Der zweite Punkt (1, 0) verläuft auf der x-achse 1 Einheit nach rechts. Da der z-wert bei beiden Punkten 0 beträgt, können wir die Linie erst sehen, wenn wir das Koordinatensystem temporär nach hinten verschieben wie bisher benutzen wir dafür das glpushmatrix()/glpopmatrix()-pärchen. Die Translation der z-achse beträgt: -znear Wir haben die Linie also Einheiten vor die znear-clipping Pane verschoben können die Linie also gerade so sehen. Nach rechts verläuft die Linie noch viel weiter über den Display-Rand hinaus: Die Strecke bis zum rechten Bildrand hängt von der Perspektive, der Screen-Auflösung und von der z-position ab und beträgt ungefähr Einheiten. 1 Aber Achtung: Wenn Sie eine Linie dieser Länge rendern wollen, müssen Sie in der drawline-methode natürlich zuvor den passenden Datentyp wählen, statt GLbyte/GL_BYTE nun Glfloat/GL_FLOAT. Wenn wir später mit 3D-Modellen arbeiten, werden wir grundsätzlich den GLfloat- Datentyp verwenden. Als Nächstes steht das OpenGL ES-Hello World an, wieder ein Dreieck, diesmal geben wir die z-koordinate aber explizit an. - (void) drawtriangle { GLbyte vertices[ ] = { -1, 1, 0, //Vertex 1 1, -1, 0, //Vertex 2 1, 1, 0 //Vertex 3 1 Sie können den Wert durch Ausprobieren ermitteln oder rechnerisch, indem Sie die Screen-Koordinaten auf die 3D- Weltkoordinaten umrechnen: Also der umgekehrte Weg, um die Daten in den Framebuffer zu schieben. Eine Beschreibung finden Sie unter anderem bei [Fournier et. al.]. 243

12 5 Die dritte Dimension: 3D-Spiele }; glpushmatrix(); glcolor4f(0, 1, 0, 1); glvertexpointer(3, GL_BYTE, 0, vertices); //3 Werte pro Eckpunkt gltranslatef(0, 0, -6); //Etwas weiter nach hinten schieben gldrawarrays(gl_triangle_strip, 0, 3); //3 = Anzahl Eckpunkte glpopmatrix(); } Wir haben ja eben bereits gesehen, dass direkt vor der znear-clipping Pane der Abstand vom Ursprung zum seitlichen Rand knapp Einheiten beträgt (bezogen auf das aktuelle Environment). Um das Dreieck zu sehen, verschieben wir das Modell sechs Einheiten nach hinten. Beachten Sie auch, dass wir nun beim VertexPointer drei Werte pro Eckpunkt geltend machen müssen. Noch befindet sich das Dreieck parallel zur xy-ebene, es könnte sich auch um eine 2D- Grafik handeln. Verändern Sie doch mal testweise die z-koordinate(n) und beobachten die perspektivische Veränderung. Noch deutlicher können wir die 3D-Perspektive machen, wenn wir eine Fläche rotieren lassen: - (void) drawrectangle { //Rechteck aus zwei Dreiecken zusammengesetzt GLbyte vertices[ ] = { -1, 1, 0, //links oben 1, 1, 0, //rechts oben -1, -1, 0, //links unten 1, -1, 0 //rechts unten }; glpushmatrix(); glcolor4f(0, 0, 1, 1); glvertexpointer(3, GL_BYTE, 0, vertices); //3 Werte pro Eckpunkt gltranslatef(0, 0, -6); static int angle = 0; angle += 2; glrotatef(angle, 1, 0, 0); //Um die x-achse rotieren lassen gldrawarrays(gl_triangle_strip, 0, 4); //4 = Anzahl Eckpunkte glpopmatrix(); } 244

13 5.5 Texturierung von Flächen Abb. 5.5: Rotation einer Rechteckfläche Das Rechteck bestehend aus zwei Dreiecken besitzt vier Eckpunkte, die die Rechteckfläche mittig über dem Ursprung aufspannen. Die Rotation erfolgt um die x-achse herum. Ein derartiges Rechteck können wir natürlich auch mit einer Textur bespannen und so aus jedem 2D-Spiel flugs ein 3D-Spiel machen. Natürlich besitzt die im Beispiel gerenderte Fläche kein Volumen Modelle mit räumlicher Ausdehnung werden wir uns weiter unten ansehen. Das Grundprinzip bleibt dabei gleich die Form des Objektes wird allein durch die Eckpunkte vorgegeben. 5.5 Texturierung von Flächen Aus Performance-Gründen ist es durchaus sinnvoll, ein 3D-Spiel nicht vollständig aus 3D- Modellen mit Volumen aufzubauen. Vielleicht kennen Sie aus einigen 3D-Autorennspielen diese seltsam flachen Bäume am Straßenrand, die zwar irgendwie realistisch aussehen, aber andererseits auch von jeder Seite gleich. Dies liegt daran, dass es sich dabei um, rechteckige, texturierte Flächen ohne z-ausdehnung handelt, deren Fläche stets dem Betrachter zugewandt ist. Derartige Sprites nennt man auch Billboards, und wir werden später, wenn wir über eine Kamera verfügen, Billboards zusammen mit 3D-Modellen einsetzen. Texturierte Flächen wirken aber auch interessant, wenn deren Fläche nicht immer dem Betrachter zugewandt ist. Stellen Sie sich doch mal den 2D-Fighter aus dem letzten Spiel vor, der im 3D-Raum Pirouetten drehen könnte. Um dies zu verwirklichen, müssen wir lediglich die rechteckige Grundfläche des Fighters mit der Fighter-Textur bespannen. Mit den bereits vorgenommenen Einstellungen innerhalb des Grundgerüstes ist die Textur automatisch von beiden Seiten der Fläche zu sehen (Vorder- und Rückseite). 245