GearVR Review aus der Sicht eines Entwicklers & wichtige Einsteiger-Links für Entwickler

Ihr habt sicherlich schon das ein oder andere Review zu der GearVR gelesen, weshalb ich mich dazu entschieden habe diese Review aus der Perspektive eines Entwicklers zu verfassen. Dabei fasse ich meine ersten Eindrücke mit der Gear zusammen, gehe aber speziell auf die besonderen Eigenschaften ein, die man als Entwickler beachten sollte. Dabei versuche ich darauf zu achten, dass der Artikel sowohl für Entwickler als auch lediglich technisch Interessierte geeignet ist. Gleichzeitig sind aber auch alle wichtigen Links für Entwickler enthalten.

So zunächst, in ein paar Worten, mein erster Eindruck zur GearVR. Beim ersten auspacken wirkte die GearVR selbst, sehr wertig. Man merkt natürlich, dass die Brille im Gegensatz zu den Developer-Kits von Oculus bereits deutlich mehr an Endbenutzer gerichtet ist. Zwar ist meiner Meinung nach „Innovator Edition“ nur ein schönes Wort für „Developer Kit“, aber das ganze Produkt wirkt beim auspacken schon sehr abgerundet. Beim ersten einlegen des Note4 startet direkt das Tutorial – als VR-erfahrener Entwickler waren mir die Schritte jedoch zu kleinlich, da das ganze schon sehr intuitiv ist.

de_SM-R320NPWADBT_000272983_Standard

Erstmals im Oculus Home war ich von der sehr abgerundeten Erfahrung positiv überrascht, alle (von Oculus freigegebenen) Anwendungen können über Oculus Home heruntergeladen und gestartet werden. Beim Stöbern durch den Shop fällt auf, dass ein Android Bluetooth Gamepad derzeit quasi Pflicht ist. Eine Markierung ob eine bestimmte Anwendung ein Gamepad braucht, fehlt leider. Deshalb kann erst nach dem Herunterladen und Starten, der teilweise großen Spiele herausgefunden werden, ob ein Gamepad Pflicht ist.

Das Gamepad liegt an sich gut in der Hand und hat ein elegantes Design, welches nicht zu sehr nach Videospiel aussieht und so auch im Business Bereich bei Präsentationen eingesetzt werden kann. Die Joysticks sind zwar konkav und haben kleine Noppen die ein abrutschen verhindern sollen, leider funktioniert dies nicht zu 100%, in hektischen Situationen rutsch der Daumen schon mal ab.

Samsungs Gamepad für die GearVR.

Insgesamt ist das Line-Up bisher sehr casual-mäßig, jedoch gehe ich davon aus, dass dies, wie auch schon bei anderen Mobilegames, ohnehin den Großteil der Spiele ausmachen wird. Kleine Spiele für zwischendurch wie Nightmare Terror oder Experiences wie Deep Blue. Das beste Spiel bisher ist meiner Meinung nach Herobound. Man benötigt ein Gamepad dafür und es bietet nicht sonderlich Spieltiefe, aber die Perspektive und das schnelle Gameplay sorgt dafür, dass es nicht so schnell langweilig wird die Dungeons zu erkunden. Außerdem ist die Musik sehr atmosphärisch.

Die Auflösung der Brille ist deutlich höher und wirkt dem Screendoor-Effekt entegen, das ist gut! Auch die an die eigene Sehschwäche anpassbaren Linsen fallen positiv auf. Negativ hingegen fällt auf, dass die Linsen merkbar kleiner sind als beim Oculus Rift Development Kit 2. Aufgrund dessen ist das Field of View so wie der Bereich den man scharf sehen kann auch deutlich geringer. Bewegt man also die Augen und schaut nicht genau durch das Zentrum der Linsen, wird das Bild viel schneller unscharf als bei der großen Schwester. Wie diese und andere Eigenschaften der GearVR die Entwicklung negativ bzw. positiv beeinflussen erfahrt ihr im nächsten Abschnitt.

Die Entwicklung mit Unity für GearVR

Wenn man nun eine Anwnedung für die GearVR entwickelt, sollte man einige Besonderheiten beachten um die perfekte Erfahrung bieten zu können. Am besten fangen wir mit den Einschränkungen an und enden dann mit den positiven Eigenschaften auf einer hohen Note!

DK2 SDK und GearVR SDK können nicht gleichzeitig in einem Unity Projekt sein

Portiert man seine Anwendung von dem Oculus Rift Development Kit 2 zur Gear VR, steht man schnell vor dem Problem, dass das Mobile SDK und das Oculus Rift SDK derzeit 2 vollständig getrennte SDKs sind. Sie ähneln sich zwar sehr stark, sind aber nicht austauschbar. Zudem können sie nicht beide gleichzeitig in einem Projekt sein. Möchte man seine Anwendung für PC und GearVR testen und erstellen, muss man die SDKs jedes mal wenn man die Plattform wechselt austauschen. Dabei muss der Plugins-Ordner zunächst vollständig gelöscht werden und dann das Unitypackage des jeweiligen SDKs importiert werden.

Tubrobutton auf aug GitHub ein kleines Tool veröffentlicht, welches dem Entwickler die Arbeit abnimmt! Einfach sein Unitypackage importieren und der Anleitung in der Readme folgen. Danach kann man mit wenigen Klicks ganz bequem das SDK tauschen. Derzeit ist das Tool für das Mobile SDK 0.4.2 und noch nicht das 0.4.3 SDK, welches sich, anders als die alte Version, an dem 0.4.4 Oculus Rift SDK orientiert. Der betroffene Code lässt sich jedoch sicherlich schnell umschreiben bzw. erwarte ich auch ein Update des Helfertools.

Projekt Einrichten

SDK rein und „Build and Run“ klicken, reicht leider nicht aus. Es müssen beim erstmaligen Einrichten noch diverse andere Einstellungen getätigt werden, bevor das Projekt problemlos auf der GearVR läuft.

Reddit User marginalvr hat die wichtigsten Schritte in Form einer TODO Liste zusammengefasst.

Anwendung Teilen

Nur Geräte für die eine Oculus Signatur im „/Assets/Plugins/Android/assets“-Ordner liegt können die selbst erstellte Anwendung ausführen. Das bedeutet man kann seine APK-Datei nicht einfach verteilen und jeder kann die Anwendung testen, da die Anwendung für jede DeviceID freigeschaltet werden muss. Erst nach dem die Anwendung zur Prüfung an Oculus geschickt und dann für den Oculus Store freigeschaltet wurde, kann die Anwendung von jedem Anwender installiert werden. Damit die Anwendung nicht durch die Prüfung fällt, sollte man sich an diesen Guide halten.

Dies ist einerseits verständlich, da Oculus nicht möchte das schlechte VR Anwendung den Ruf der GearVR beschmutzen. Andererseits ist dies aus Entwicklersicht auch Schade, da man seine Anwendung nicht einfach veröffentlichen kann, sondern von Oculus abhängig ist.

Kein Positionstracking

Derzeit hat die GearVR kein Positionstracking. Dies muss bei der Umsetzung der Idee in jedem Fall beachtet werden: Denn ein nach vorne lehnen wie bei der DK2 ist nicht möglich. Besonders wichtig ist dieses Manko bei Portierungen von Spielen die von dem Development Kit 2 kommen. John Carmack arbeitet jedoch bereits seit geraumer Zeit an einem „Inside-Out“ Tracking, bei dem eine Kamera an der GearVR (zum Beispiel die interne Kamera des Note4) benutzt werden kann um die Umgebung zu erkennen und so Positionstracking zu ermöglichen.

Kleinere Linsen = kleinerer Schärfeberreich, kleineres Field of View

de_SM-R320NPWADBT_000272965_StandardDurch die kleineren Linsen der GearVR ist der Schärfeberreich und das Field of View deutlich kleiner als bei dem Development Kit 2. Dies muss bei der Umsetzung von Levels, Cockpits und Bedienelementen wie Menüs beachtet werden. Am besten kann man dass in einer Grafik sehen. Die Grafik dient nur der Veranschaulichung und entspricht nicht dem tatsächlichen Unterschied!

Menü-Elemente müssen also ggf. anders positioniert, anders skaliert oder die Kamera verschoben werden, damit auf beiden Geräten das gleiche Erlebnis erlebt werden kann. An der Frage, ob das kleinere Field of View die Immersion beeinträchtigt scheiden sich die Geister: Die einen finden das Development Kit 1 mit seinem hohen Field of View immer noch am immersievsten, für die anderen trägt die deutlich höhere Auflösung der Gear zur besseren Immersion bei. Egal welche Position man hier bezieht, für eine gute Portierung von der DK2 sollte man auch die kleinen Optiken beachten.

Beschränkte Leistung

note4Das Note4 ist stark, hat aber natürlich nicht so viel Leistung wie ein ausgewachsener PC. Entwickelt man eine Anwendung für die GearVR muss man also einiges beachten. E MCNeil, der Entwickler von Darknet, hat kürzlich seine Erfahrungen geteilt, wo das Note4 an seine Grenzen stößt: 60 FPS bei 1440p in stereoskopischen 3D, das kostet deutlich mehr als das Rendern für den normalen Monitor. Man sollte schon vor dem Coden beginnen sich über die Performance Gedanken zu machen, dies ist meiner Meinung nach ein Tipp den man ohnehin immer befolgen sollte.

Um einmal ein paar Zahlen zu nennen, MCNeil gibt folgende grobe Grenzen an:

  • 50 – 100 Drawcalls
  • 50.000 bis 100.000 Triangles
  • 50.000 bis 100.000 Vertices

Auf Echtzeit Schatten, Echtzeit reflektierende Flächen sowie andere -optisch beeindruckende- Elemente welche die Drawcall nach oben treiben, sollte (muss) man also verzichten.

60Hz Flackern

Der Bildschirm aktuallisiert sich nur mit 60 statt 75 Bildern pro Sekunde, dadurch kann bei der GearVR bei großen hellen/weißen Flächen häufig ein Flackern festgestellt werden. Entwickler sollten also darauf achten und solche Problemfelder vermeiden.

Umständliches Debuggen

Mit Unity ist das Debuggen von Android Anwendungen leider nicht so einfach wie das Debuggen einer Anwendung für den PC. Erschwerend kommt hinzu, dass wir die USB-Verbindung kappen müssen und somit die Log-Daten nicht über USB an den PC senden können. Doch das Android SDK hat hier vorgesorgt: Das SDK erlaubt W-Lan Deployment und Logging. Anwendungen können also kabellos ohne USB-Verbindung auf das Handy installiert und Debug-Logs gelesen werden.

Da 3D-Anwendungen schnell sehr groß werden, ist das Installieren der Anwendungen via W-Lan leider nicht zu empfehlen, denn der Vorgang ist bedeutend langsamer als via USB. Mein Workflow ist also, Deployment via USB und Logging via W-Lan.

Titans of Space Entwickler Drash hat im OculusVR-Forum ein paar Batch-Dateien veröffentlicht, mit welchen man das (De-)Aktivieren, Verbinden und Loggen mit wenigen Clicks einrichten kann.

Trotz all dem ist das debuggen deutlich langsamer und umständlicher als am PC. Eine live Vorschau in der Hierarchie, Szenen Ansicht oder im Inspektor gibt es zum Beispiel nicht und muss vollständig via Debug Logs erledigt werden.

Zum Positiven

Time Warp funktioniert!

Im Gegensatz zu den PC-Varianten des SDKs klappt Timewarp auf der Gear ohne Probleme. Was bedeutet dies? Timewarp erlaubt es, dass das Headtracking unabhängig von der FPS Zahl geupdatet werden kann. Fällt die FPS unter die Bildfrequenz (60 bei GearVR, 75 bei DK2) ruckelt ohne TimeWarp (also bei der DK2) das Headtracking, so dass man ein „Hinterherziehen“ bemerken kann. In der PC-Variante des SDKs sind Einstellungsmöglichkeiten für das Feature schon von Anfang an enthalten, allerdings funktioniert es derzeit nicht. Auf dem Note4 und dem GearVR klappt es jedoch ohne Probleme.

Fällt die FPS unter 60 und es steht beim nächsten Update kein neuer Frame, aber Tracking-Informationen bereit, dann wird das alte Bild erneut angezeigt, jedoch wird die virtuelle Kamera auf dem alten Bild verschoben, sodass es optisch so aussieht, es wäre ein neues Bild von der GPU gekommen. Dieser Trick klappt natürlich nur, wenn die Zeiten zwischen den Bildern nicht zu groß werden und noch ausreichend altes Bildmaterial zu Verfügung steht.

Das bedeutet, man kann auch Methoden die kurzzeitig Hardware-fordernd sind, wie zum Beispiel das Laden von neuen Level-Abschnitten, ausführen, ohne dass dem Anwender direkt schlecht wird.

Die höhere Auflösung!

Die höhere Auflösung vertreibt den Screendoor Effekt noch lange nicht vollständig, hilft aber User-Interfaces und Texte aus der Entfernung deutlich besser lesen zu können! Für Gamedesigner bedeutet dies, dass sie mehr Arbeit in die Details stecken müssen. Denn was vorher in dem Pixelgitter unterging ist heute dank der Auflösung von 2560*1440 sehr gut sichtbar.

(Da das Vive 2 Displays nutzt, anstelle von einem, nutzt es trotz geringerer Auflösung mehr Pixel als die Oculus Rift, daher sollte diese Grafik nur zum Vergleich der Oculus Hardware genutzt werden)

(Da das HTC Vive zwei Displays verbaut hat , anstelle von nur einem wie bei Oculus, nutzt es trotz geringerer Auflösung u.U. mehr Pixel als die GearVR, daher sollte diese Grafik nur zum Vergleich der Oculus Hardware genutzt werden) Quelle: reddit.com/r/oculus

Einen Eindruck vom Unterschied zwischen DK2 und GearVR könnt ihr mit dem Oculus Rift Screendoor Simulator bekommen. Der Simulator stellt nicht die tatsächliche Bild-Qualität dar und kann lediglich die Unterschiede zwischen den Auflösungen deutlich machen.

Freiheit

Nicht nur dass man die Brille überall benutzen kann und so, wie bei Handyspielen, Casual-Games immer mehr in den Vordergrund rücken, speziell die Freiheit durch das nicht vorhandene Kabel sind ein enormer Bonus. Sowohl stehend als auch sitzend, kann man sich mehrmals um die eigene Achse drehen, ganz ohne sich in Kabel zu verknoten.

Austauschbare Schoner

Die GearVR bietet von sich aus bereits austauschbare Schaumstoffpolster, was es erlaubt den Stoff nach einem Tag voll mit Demonstrationen einfach auszutauschen und den verschmutzen Schoner zu waschen. Um die originale GearVR-Schoner aber vor Abnutzung zu schützen, empfiehlt es sich meiner Meinung nach zusätzlich Schoner wie z.B. VRCover zu verwenden.OLYMPUS DIGITAL CAMERA Hier ist nämlich eine verbesserte Version gezielt für die GearVR erschienen, welche einige Fehler der Vorgänger-Variante behebt. So wird der neue Schutz z.B. mit Klettverschlüssen an der Halterung des GearVR-Schoners befestigt, wodurch die neue Variante beim Aufsetzen nicht mehr so leicht verrutschen kann. Gerade für Entwickler oder Meetup-Besucher die ihre Brille häufig auf fremde Gesichter setzen oder normale Anwender, die ihre original-Hardware vor Schmutz und Abnutzung schützen wollen, ist der zusätzliche Schutz nochmal ein großer Bonus!

 

So ich hoffe ich konnte euch einen guten Überblick zur GearVR aus meiner Entwickler-Perspektive geben! Mir gefällt die Brille, jedoch sehe ich die Zukunft von „Hardcore“ VR-Anwendungen  weiterhin nur am PC.

 


Bloculus.de ist Teilnehmer des Affiliate Programms von VRCover. Kauft ihr also über einen Link auf Bloculus.de euer Cover, erhält Bloculus.de einen kleinen Anteil des Kaufpreises, ohne dass es für euch mehr kostet. Von dem Geld werden dann Ausgaben für die Webseite finanziert. Ich habe mich für die Teilnahme am Programm entschieden, weil ich persönlich von VRCover überzeugt bin und alle meine Brillen nur mit diesem Schutz benutze und demonstriere.

 

Daniel Korgel

Geschrieben von

Ich bin Daniel Korgel und bin ein selbständiger Software Entwickler im Bereich Virtual Reality. Ich programmiere in meiner Freizeit schon sehr lange und bin gut unterwegs mit C# (& .Net), Java, HTML, PHP und MYSQL. Kenntnisse in C, C++ und Assembler sind aber auch vorhanden. Zudem arbeite ich derzeit auch an meinem Bachelor. In meiner Freizeit sammle ich alte Spielekonsolen und bin auch hin und wieder im Skatepark anzutreffen. Twitter: @DakorVR , @Bloculus_de| Xing: xing.com/profiles/Daniel_Korgel


Kommentar verfassen