Godot auf XREAL AURA: Ein praktischer Leitfaden für native Spatial-Entwicklung

Deine XR-Build-Pipeline bedeutet derzeit: an einen Desktop anschließen, eine APK exportieren, per ADB sideloaden, die Brille aufsetzen, einen Tippfehler entdecken und von vorn beginnen. XREAL AURA entfernt diese Schleife komplett, und Godot ist beim Start mit dabei – mit einem vollwertigen Editor, der direkt auf der Brille läuft. Das verändert, was „iterieren“ für die Spatial-Entwicklung bedeutet.

Dieser Leitfaden führt durch den tatsächlichen Workflow: den Editor auf AURA zum Laufen bringen, eine Spatial-Szene mit OpenXR Spatial Containers strukturieren, das Passthrough/See-through-Modell verstehen, das optische Gläser von VR-Headsets unterscheidet, und die Fallstricke, die dich beim ersten Export beißen werden.

Warum optisches See-Through deine Design-Annahmen verändert

XREAL AURA ist das erste optische See-Through-Gerät auf Android XR. Dieser eine Satz bricht mit Annahmen, die in den meisten Godot-XR-Tutorials eingebaut sind.

In einem VR-Headset rendert die Headset-Kamera alles. Der Nutzer sieht deine Umgebung und sonst nichts. Bei optischen See-Through-Gläsern sieht der Nutzer durch die Linsen auf die reale Welt, und deine gerenderten Inhalte werden darübergelegt. Das ist nicht dasselbe wie Video-Passthrough bei einer Quest – Video-Passthrough erfasst die Realität mit Kameras und zeigt sie erneut an, was Latenz und Lichtverlust einführt. Optisches See-Through hat null Compositor-Latenz für die reale Welt.

Praktische Konsequenzen für dein Rendering-Budget:

• Du kannst die reale Welt nicht abdunkeln. Schwarz auf einem transparenten Display ist transparent. Du hast keinen opaken Hintergrund, daher versagt UI, die auf Kontrast gegen dunkle Panels setzt, in einem hellen Raum.
• Additiv wirkende Inhalte gewinnen. Helle, emittierende Inhalte sind gut lesbar; dunkle, entsättigte Inhalte verschwinden. Gestalte deine Palette mit der 2-3-fachen Leuchtdichte, die du in VR verwenden würdest.
• Das Sichtfeld ist schmaler als bei VR. Inhalte, die in extremen Winkeln platziert sind, fallen außerhalb des Anzeigebereichs. Halte primäre Interaktionsziele innerhalb von ungefähr ±30 Grad um die Vorwärtsrichtung.

Wenn du bereits VR veröffentlicht hast, erwarte, jedes Material und jedes UI-Panel neu abzustimmen. Plane einen ganzen Tag pro Szene ein.

Den Godot-Editor auf der Brille einrichten

Der Editor wird über Google Play verteilt, nicht als sideloaded APK. Das ist wichtig, weil du ihn so wie jede andere App aktualisieren kannst.

Die Einrichtungsschritte:

1. Installiere den Godot-Editor auf der XREAL AURA aus dem Play Store.
2. Installiere die begleitende Gradle-Build-Umgebungs-App. Sie liefert die Android-Export-Toolchain, sodass du nicht JDK und Android SDK auf dem Gerät von Grund auf neu aufbauen musst.
3. Melde dich mit einer Android-Entwickleridentität an, wenn du Builds auf dem Gerät signieren und veröffentlichen willst.
4. Starte den Editor – er öffnet sich in einem Multi-Window-Spatial-Workspace statt in einem einzelnen flachen Fenster.

Der vierte Punkt ist der interessante. Der Editor bietet dir den Desktop-Funktionsumfang, aber angeordnet als schwebende Fenster im Raum. Du kannst den Szenenbaum in einem Volume und den 2D-Viewport in einem anderen behalten.

Was der On-Device-Workflow dir tatsächlich bringt

Die ehrliche Antwort: schnelle Iteration beim Feel, langsamere Iteration bei Assets.

Shader bearbeiten, Node-Transforms justieren und Input-Mappings auf dem Zielgerät testen eliminiert den gesamten Export-Test-Zyklus. Dieser Zyklus dauert normalerweise 3-8 Minuten, wenn man Build-Zeit, Transfer und Neustart einrechnet. Zehn Iterationen sind eine Stunde verloren.

Wobei er nicht hilft: große Textur-Atlanten importieren, lange Lightmap-Bakes laufen lassen oder alles CPU-lastige. Das machst du am besten auf einer Workstation. Die realistische Aufteilung ist Asset-Erstellung am Desktop, Szenenaufbau und -Feinabstimmung auf der Brille.

Spatial-Inhalte mit OpenXR Spatial Containers erstellen

Godots Android-XR-Unterstützung umfasst OpenXR Spatial Containers – systemverwaltete Volumes, in denen deine App Spatial-Inhalte platziert. Die Analogie der Plattform selbst ist ziemlich treffend: Traditionelle Apps zeichnen 2D-Inhalte in Fenstern auf einem Desktop; Spatial-Apps zeichnen 3D-Inhalte in Containern in einem Raum.

Es gibt zwei Containertypen, die du verstehen solltest, bevor du Code schreibst:

Containertyp	Am besten geeignet für	Kompromiss
Volume	3D-Objekte mit echter Tiefe, weltverankerte Platzierung	Das System kann die Volumengrenzen begrenzen
Panel	UI-Oberflächen, Text, 2D-Spiele	Wird auf einer festen Ebene gerendert; Tiefenhinweise sind flach

Der Fehler, den die meisten Entwickler machen, ist, Volume für UI zu wählen. Text in einem Volume-Container wird vom System auf eine Weise skaliert und bewegt, die du nicht vollständig vorhersagen kannst, und dein sorgfältig positioniertes Radar-Widget driftet. Setze UI in einen Panel-Container und lass das System die Platzierung übernehmen.

Mit der Spatial-Container-API arbeiten

Godot stellt Spatial Container über OpenXR-Erweiterungsklassen bereit. Die genauen Klassennamen hängen von deiner Godot-Version ab. Prüfe also die Feature-Liste der Engine für die aktuellen Spatial-Container-Bindings, bevor du Produktionscode schreibst. Das Muster unten spiegelt wider, wie containerbasierte XR-Inhalte typischerweise strukturiert sind.

extends Node3D

signal container_created(handle: int)

# Spatial container setup for Android XR.
# Class names are version-dependent; verify against the
# OpenXR extension bindings shipped with your Godot build.

var volume_container: SpatialContainer
var panel_container: SpatialContainer

func _ready() -> void:
    var xr_interface: XRInterface = XRServer.find_interface("OpenXR")
    if xr_interface == null or not xr_interface.is_initialized():
        push_error("OpenXR interface unavailable on this device.")
        return

    # Volume container for the 3D board.
    volume_container = SpatialContainer.new()
    volume_container.container_type = SpatialContainer.TYPE_VOLUME
    volume_container.extent = Vector3(0.6, 0.4, 0.6)  # 60cm x 40cm x 60cm
    if volume_container.request_container() != OK:
        push_error("Volume container request failed.")
        return

    # Panel container for the HUD.
    panel_container = SpatialContainer.new()
    panel_container.container_type = SpatialContainer.TYPE_PANEL
    panel_container.extent = Vector3(0.4, 0.4, 0.02)
    panel_container.request_container()

    add_child(volume_container)
    add_child(panel_container)

    container_created.emit(volume_container.get_container_handle())

func _process(_delta: float) -> void:
    # Containers can be rejected or resized by the system.
    if volume_container and not volume_container.is_active():
        _handle_container_loss()

func _handle_container_loss() -> void:
    push_warning("Volume container lost - repositioning.")
    # Never assume the container survives; re-request on loss.
    volume_container.request_container()

Die kritische Zeile ist _handle_container_loss(). Systemverwaltete Container werden per Definition vom System verwaltet. Der Nutzer geht weg, der Assistent positioniert Inhalte neu, oder das Gerät beansprucht Platz zurück. Wenn deine Eingabebehandlung einen Container-Verlust nicht übersteht, sitzt deine App mit einem unsichtbaren Board da, während der Spieler auf Knöpfe hämmert.

Die Falle, auf die fast alle hereinfallen: Anchor Drift

Hier ist das konkrete Problem, und es wird dich die meiste Debugging-Zeit kosten.

Du platzierst ein 3D-Board in einem Volume-Container. Du drückst Play. Alles sieht richtig aus. Du nimmst die Brille ab, setzt sie zwei Minuten später wieder auf, und das Board ist jetzt einen halben Meter links verschoben und um 20 Grad gedreht.

Warum? Weil du deine Inhalte am Weltursprung verankert hast statt am Container. Der Weltursprung auf einem Spatial-Gerät ist kein stabiler Ort – er ist relativ zur Start-Pose der Session definiert. Wenn die Session neu verankert wird, bewegt sich der Weltursprung.

Die Lösung: Behalte jedes Element deiner Szene als Kind des Container-Transforms und lies oder schreibe niemals globale Positionen für Spatial-Inhalte:

# WRONG: assumes world origin is stable
func place_piece(piece: Node3D, board_pos: Vector3) -> void:
    piece.global_position = board_pos

# RIGHT: position relative to the container transform
func place_piece(piece: Node3D, board_pos: Vector3) -> void:
    piece.position = board_pos   # local to container
    piece.rotation = Vector3.ZERO

Mach vor dem Release einen Grep über dein Projekt nach .global_position und .global_transform. Jeder Treffer in Spatial-Inhalten ist ein potenzieller Drift-Bug. Diese Art von Bug tritt auch in konventioneller 3D- und Multiplayer-Arbeit auf – Anker- und Ownership-Fehler bei einem replizierten Transform erzeugen genau dasselbe Symptom „Objekt wurde für manche Clients teleportiert“. Deshalb ist es eine Gewohnheit, die sich in jedes vernetzte Godot-Projekt lohnt: Transforms als container-lokal statt absolut zu behandeln.

Den Fix verifizieren

So bestätigst du, dass die Verankerung stimmt:

1. Starte deine Szene und notiere die Position des Boards.
2. Entferne das Gerät, warte 60 Sekunden und öffne die App erneut.
3. Das Board sollte an derselben physischen Position relativ zum Raum erscheinen, nicht mit demselben Offset von deinem aktuellen Standort.
4. Wiederhole das mit dem Gerät in einer anderen Ausrichtung – sitzend, dann stehend.

Wenn es drifft, enthält dein Szenenbaum immer noch absolute Referenzen. Wenn es springt, aber nach dem Sprung stabil bleibt, wird der Container neu positioniert und deine Inhalte folgen korrekt – das ist erwartetes Verhalten, kein Bug.

Spieleridentität und persistente Zustände verwalten

Spatial-Apps auf Android XR sind Android-Apps. Sie werden pausiert, sie werden fortgesetzt, der Nutzer kann mehrere angemeldete Identitäten auf dem Gerät haben, und deine Speicherdaten leben im selben Account-Ökosystem wie alles andere.

Der Fehlermodus ist subtil: Ein Spieler spielt räumlich auf der Brille und öffnet dann dasselbe Spiel auf dem Handy. Wenn dein Speicherstand geräte-lokal ist, hat er jetzt zwei divergierende Welten und keine Möglichkeit, sie zu vereinbaren. Das zu beheben ist kein Rendering-Problem, sondern ein Account-Identitäts-Problem.

Wenn du es selbst richtig machen willst, brauchst du Sign-in-Flows, einen serverseitigen Speicher und – der Teil, den alle unterschätzen – Konfliktbehandlung, wenn zwei Geräte in denselben Speicherplatz schreiben. Ein revisionsbewusstes Lese-/Schreibmodell, bei dem der Client Versionen vergleicht und Konflikte explizit auflöst, ist die einzige Variante, die den Kontakt mit echten Nutzern überlebt. Das von Grund auf neu zu bauen ist eine Aufgabe für mehrere Wochen; horizOn bietet genau dafür accountgebundenen Cloud-Save mit revisionsbewussten Lese- und Schreibvorgängen, dazu E-Mail-, anonyme, Google- und Apple-Authentifizierung, sodass dieselbe Spieleridentität auf Brille und Handy funktioniert.

Egal welches Backend du verwendest, entscheide die Konfliktrichtlinie vor dem Release. Last-write-wins zerstört stillschweigend Fortschritt. Den Spieler zu fragen ist besser, als Daten zu verlieren.

Best Practices für die Veröffentlichung auf XREAL AURA

1. Gestalte für Umgebungslicht. Teste jedes UI-Panel draußen mittags und in einem dunklen Raum. Wenn dein Text in einem der beiden Fälle unleserlich wird, erhöhe den Kontrast und füge eine dezente helle Kontur hinzu statt eines dunklen Schattens – Schatten bewirken auf einem transparenten Display nichts.
2. Halte Container klein und erneut anforderbar. Ein 60-cm-Volume lässt sich vom System zuverlässiger platzieren als eines mit 2 m. Geh davon aus, dass jeder Container jederzeit verloren gehen kann, und schreibe den Recovery-Pfad zuerst, nicht zuletzt.
3. Begrenze dein Render-Budget aggressiv. Das sind Gläser, keine Desktop-GPU. Ziele auf eine Frame-Zeit unter 11 ms (90-Hz-Klasse) und deaktiviere temporales Anti-Aliasing zugunsten von MSAA, das bei Spatial-Auflösungen günstiger ist.
4. Setze UI in Panels, Inhalte in Volumes. Kämpfe nicht gegen die Platzierungslogik des Systems bei Text. Reserviere Volumes für Dinge mit echter Tiefe, die der Spieler aus mehreren Blickwinkeln betrachtet.
5. Verifiziere auf dem Gerät vor jedem Meilenstein. Der Editor auf der Brille macht das günstig. Simulatorergebnisse zeigen weder Anchor Drift noch Leuchtdichtefehler oder Container-Verlust-Verhalten.

Der nächste Schritt

Der On-Device-Editor ist hier die eigentliche Schlagzeile. Er verkürzt die Spatial-Iterationsschleife von Minuten auf Sekunden, und genau das ist der Unterschied zwischen einem Design zu optimieren und einem Design zu raten.

Installiere zuerst den Editor und die begleitende Gradle-App auf der AURA, und baue dann ein kleines bestehendes Projekt als Spatial-Szene neu auf, statt bei null anzufangen – du wirst die Verankerungs- und Leuchtdichteprobleme sofort an Inhalten sehen, die du bereits kennst. Füge danach einen 3D-Volume-Container und ein UI-Panel hinzu und bringe beide über einen Suspend/Resume-Zyklus stabil. Wenn das hält, bist du bereit, für die Plattform zu gestalten statt gegen sie.

Wenn persistenter geräteübergreifender Spielerzustand auf deiner Liste steht, übernimmt horizOn accountgebundenen Cloud-Save mit clientseitiger Konfliktlösung, sodass deine Spatial-Session und deine Flachbildschirm-Session übereinstimmen.

---

Quelle: Bereit für XREAL AURA