»GT Ride« generiert aus den Bewegungen des Mobilgeräts eine Rennstrecke und projiziert sie in die 3-D-Umgebung. Dank Unity auf (fast) allen Plattformen
Die Kollisionsebene (Mesh Collider) für das Fahrzeug generiert Unity dynamisch, um auf eventuelle Streckenüberschneidungen zu reagieren. Damit fährt das Fahrzeug nicht an die Wand, sondern bleibt auf der Fläche
Da wir »GT Ride« sowohl für einen Messestand auf der Internationalen Automobil Ausstellung in Frankfurt als auch als mobile App produzieren wollten, fiel die Wahl schnell auf Unity, denn mit der 3-D-Entwicklungssoftware kann man Projekte von Anfang an plattformübergreifend angehen. Wir konnten also das ganze Spektrum abdecken: von High-End in fünf mal drei Metern für die Messe bis zu »Low Poly« und »Low Performance« für Android-Geräte. In der Programmierung kommen lediglich Weichen zum Einsatz, die je nach Plattform auf High- oder Low-Poly-Assets zugreifen.
Die Messevariante arbeitet mit Kinect: Die Kinect-Sensoren tracken die Bewegungen der User im freien 3-D-Raum. Mittels vvvv und Unity errechnet die Anwendung daraus eine Strecke und setzt sie um. Schon wenige Momente später konnten die User ihre »gemalte« Route abfahren. Schwierigkeiten gab es anfangs beim Tracking, da hatten wir das Problem einer »zappelnden« Hand. Die Strecke sollte aber nicht zerknittert, sondern schön eben sein. Für die nötige Balance suchten wir uns einen virtuellen Fixpunkt, von dem aus wir die Strecke beginnen lassen. Das kann man sich vorstellen wie ein virtuelles Pendel, das man mit einem Gummiband an der Hand aufhängt. Dieser Fixpunkt sorgt zusätzlich für die Glättung der Strecke.
Die Messeversion realisierten wir auf einem Hochleistungs-PC mit einer Nvidia-GeForce-GTX-760-Grafikkarte. Sie steckt in den typischen Gamer-PCs und erlaubt die Darstellung von rund fünf Millionen in Echtzeit generierten Polygonen, Echtzeitschatten und einigen Postprocessing-Shadern (Bloom, Camera-Motion-Blur, zusätzliches Antialiasing), die den Look maßgeblich prägen und unterstützen.
Die meist etwas krakeligen Kinect-Rohdaten (gelbe Linie) verwandeln Glättungsalgorithmen in eine befahrbare Strecke (magentafarbene Linie)
Looping oder Pirouette?
Anders erging es uns bei der mobilen Version. Es war gar nicht so leicht, die Gyroskopdaten zur Drehung des Geräts im Raum in eine Rennstrecke zu transformieren, denn die Bewegungen des eigentlich blinden Geräts lassen sich nur schwer einwandfrei im 3-D-Raum verorten. Vollführt der User gerade einen Looping oder doch eine Drehung? Man weiß es nicht. Das Gerät kennt zwar seinen eigenen Neigungswinkel, jedoch nicht die Stelle, an der es sich befindet. GPS-Daten wären zu ungenau. In einer gleichmäßigen Vorwärtsbewegung des Geräts kommen wir jedoch recht nah an das eigentliche räumliche Setting heran.
Ab dem Moment, in dem der User auf »Aufnahme« drückt, checkt das Smartphone den Neigungswinkel des Geräts und schiebt es virtuell ein Stückchen nach vorn. Eigentlich sind Smartphones nämlich ganz schön dumm. Sie erkennen Drehungen zwar ganz gut, doch die Bewegungsrichtung und -stärke lässt sich nur schwer auswerten.
Es ist ein bischen so, als ob man mit verbundenen Augen tauchen geht und im Nachhinein die zurückgelegte Strecke skizzieren sollte.
Wir behandeln das Smartphone also wie einen Papierflieger, der pro Sekunde die Distanz x zurücklegt – wir registrieren die einzelnen Neigungswinkel und ziehen mithilfe verschiedener Glättungsalgorithmen dazwischen eine Linie, die eine Gerade oder Kurve sein kann. Unity verbindet dann die Linien zwischen Neigungswinkeln und generiert daraus eine befahrbare Strecke, indem sie Parameter wie »Kurvigkeit«, »Komplexität«, »Geraden« et cetera definiert. Architektonische Aufbauten wie Brücken, Tunnel, Pfeile oder Halteseile verteilt Unity per Zufallsgenerator dem Charakter der Strecke entsprechend und verleiht dadurch jedem einzelnen Track einen individuellen Look.
Polygonen sparen
Die Herausforderung beim »Downgraden« auf die mobile Version bestand darin, mit einem Hundertstel der Polygondaten auszukommen. Circa 50 000 Polygone mussten reichen, um eine attraktive Spielatmosphäre zu erzeugen. Schwierig, denn vor allem das Auto sollte auf Wunsch des Kunden sehr realistisch aussehen. Da der gesamte Aufbau der Strecke echtzeitgeneriert ist, konnten wir nicht auf die Unity-internen Pre-compile-Optimierungsprozesse zurückgreifen, die normalerweise die grafische Performance optimieren. Einer dieser Prozesse nennt sich Occlusion Culling, das die gesamte 3-D-Welt segmentiert und nach einem komplizierten Algorithmus von der Kameraposition aus gesehen bestimmte (nicht sichtbare) Bereiche von vorneherein nicht in den Renderdurchlauf bringt. Die Reduzierung von Shadern, die Verschlankung des Autos von 10 000 auf 5000 Polygone sowie der geringere Lichteinsatz brachten die Gesamtperformance der mobilen Version letztlich allerdings doch auf ein hervorragendes Level. Sowohl das Auto als auch die Rennstrecken sind gestochen scharf.
Testing bis zur letzten Sekunde
Wenn man iterativ entwickelt, muss man die Prototypen früh und umfassend testen.
Außerdem bezogen wir hier den Kunden von Beginn an mit ein, sodass wir das Feedback aller Beteiligten berücksichtigen und umsetzen konnten. Aufgrund der örtlichen Distanz aller Parteien testen wir mithilfe der Betatesting-Software TestFlight, mit der man eine App-Vorabversionen auch ohne App Store installieren kann.
Auch das Bugtracking erfolgte auf einer zentralen Plattform, sodass wir das Feedback zusammenfassen, ordnen und strukturiert abarbeiten konnten. Zudem durften alle Beteiligten den aktuellen Entwicklungsstand einsehen und gemeinsam die Prioritäten einzelner Vorgänge definieren. Um Einsichten in das Nutzungsverhalten durch projektferne Personen zu erhalten, ließen wir eine externe Fokusgruppe die App testen. Mit den Ergebnissen konnten wir das Interface und die Funktionen weiter für den Live-Gebrauch optimieren.
