Godot su XREAL AURA: Guida pratica allo sviluppo spaziale nativo

La tua pipeline di build XR oggi significa restare collegato a un desktop, esportare un APK, trasferirlo via ADB, indossare il visore, scoprire un refuso e ricominciare da capo. XREAL AURA elimina del tutto questo ciclo e Godot è nella lineup di lancio con un editor completo che gira direttamente sugli occhiali. Questo cambia il significato di "iterare" per lo sviluppo spaziale.

Questa guida illustra il flusso di lavoro reale: far girare l'editor su AURA, strutturare una scena spaziale con gli OpenXR Spatial Containers, gestire il modello passthrough/see-through che distingue gli occhiali ottici dai visori VR, e le insidie che ti morderanno al primo export.

Perché l'Optical See-Through Cambia le Tue Assunzioni di Progettazione

XREAL AURA è il primo dispositivo optical see-through su Android XR. Questa singola frase rompe le assunzioni incorporate nella maggior parte dei tutorial Godot XR.

In un visore VR, la fotocamera del visore renderizza tutto. L'utente vede il tuo ambiente e nient'altro. Sugli occhiali optical see-through, l'utente vede attraverso le lenti il mondo reale, e il tuo contenuto renderizzato viene composto sopra. Non è la stessa cosa del video passthrough su un Quest: il video passthrough cattura la realtà con le fotocamere e la ridisplaya, introducendo latenza e perdita di luce. L'optical see-through ha zero latenza di composizione per il mondo reale.

Conseguenze pratiche per il tuo budget di rendering:

• Non puoi oscurare il mondo reale. Il nero su un display trasparente è trasparente. Non hai uno sfondo opaco, quindi una UI che si affida al contrasto su pannelli scuri fallirà in una stanza luminosa.
• Il contenuto dall'aspetto additivo vince. Il contenuto emissivo brillante si legge bene; il contenuto scuro e desaturato sparisce. Progetta la tua palette con una luminanza 2-3 volte superiore a quella che useresti in VR.
• Il campo visivo è più stretto che in VR. Il contenuto posizionato ad angoli estremi cade fuori dall'area di visualizzazione. Tieni i bersagli di interazione primari entro circa ±30 gradi dal centro frontale.

Se hai già pubblicato in VR, aspettati di ricalibrare ogni materiale e ogni pannello UI. Metti in conto un giorno intero per scena.

Configurare l'Editor di Godot sugli Occhiali

L'editor è distribuito su Google Play, non come APK sideloadato. Questo è importante perché significa che puoi aggiornarlo come qualsiasi altra app.

La sequenza di configurazione:

1. Installa l'editor di Godot su XREAL AURA dal Play Store.
2. Installa l'app complementare per l'ambiente di build Gradle. Questa include la toolchain di export Android, quindi non devi costruire JDK e Android SDK da zero sul dispositivo.
3. Accedi con un'identità di sviluppatore Android se hai intenzione di firmare e pubblicare build dal dispositivo.
4. Avvia l'editor: si apre in uno spazio di lavoro spaziale multi-finestra invece di una singola finestra piatta.

Il quarto punto è quello interessante. L'editor offre il set di funzionalità in stile desktop, ma disposto come finestre fluttuanti nello spazio. Puoi tenere l'albero della scena in un volume e il viewport 2D in un altro.

Cosa Ti Dà Realmente il Workflow On-Device

La risposta onesta: iterazione veloce sul feel, più lenta sugli asset.

Modificare shader, regolare le transform dei nodi e testare le mappature di input sul dispositivo target elimina l'intero ciclo export-test. Quel ciclo richiede tipicamente 3-8 minuti se consideri build, trasferimento e rilancio. Dieci iterazioni significano un'ora persa.

Ciò con cui non aiuta: importare grandi texture atlas, eseguire lunghi bake di lightmap o qualsiasi operazione CPU-intensive. Fallo su una workstation. La suddivisione realistica è creazione di asset sul desktop, assemblaggio e regolazione della scena sugli occhiali.

Creare Contenuti Spaziali con gli OpenXR Spatial Containers

Il supporto Android XR di Godot include gli OpenXR Spatial Containers: volumi gestiti dal sistema in cui la tua app posiziona contenuti spaziali. L'analogia della piattaforma stessa è quasi accurata: le app tradizionali disegnano contenuti 2D in finestre su un desktop; le app spaziali disegnano contenuti 3D in container in una stanza.

Ci sono due tipi di container che vale la pena capire prima di scrivere codice:

Tipo di container	Ideale per	Compromesso
Volume	Oggetti 3D con profondità reale, posizionamento ancorato al mondo	Il sistema può limitare i confini del volume
Panel	Superfici UI, testo, giochi 2D	Renderizzato su un piano fisso; i cue di profondità sono piatti

L'errore che la maggior parte degli sviluppatori commette è scegliere il volume per la UI. Il testo in un container di tipo volume viene scalato e spostato dal sistema in modi che non puoi prevedere completamente, e il tuo widget radar posizionato con cura va alla deriva. Metti la UI in un container a pannello e lascia che sia il sistema a gestire il posizionamento.

Lavorare con le API degli Spatial Container

Godot espone gli spatial container attraverso le classi di estensione OpenXR. I nomi esatti delle classi dipendono dalla versione di Godot, quindi controlla l'elenco delle funzionalità del motore per i binding correnti degli spatial container prima di scrivere codice di produzione. Il pattern seguente riflette come vengono tipicamente strutturati i contenuti XR basati su container.

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()

La riga critica è _handle_container_loss(). I container gestiti dal sistema sono, per definizione, gestiti dal sistema. L'utente si allontana, l'assistente riposiziona i contenuti o il dispositivo recupera spazio. Se la gestione dell'input non sopravvive alla perdita del container, la tua app resterà lì con una board invisibile e un giocatore che martella i pulsanti.

Lo Scoglio Che Quasi Tutti Colpiscono: L'Anchor Drift

Ecco il problema specifico, quello che ti costerà più tempo di debugging.

Posizioni una board 3D in un container di volume. Premi Play. Tutto sembra corretto. Ti togli gli occhiali, li rimetti due minuti dopo e la board ora è mezzo metro a sinistra e ruotata di 20 gradi.

Perché? Perché hai ancorato i tuoi contenuti all'origine del mondo piuttosto che al container. L'origine del mondo su un dispositivo spaziale non è un luogo stabile: è definita in relazione alla pose di inizio sessione. Quando la sessione si ri-ancora, l'origine del mondo si sposta.

La soluzione è tenere ogni elemento della tua scena come figlio della transform del container e non leggere o scrivere mai la posizione globale per i contenuti spaziali:

# 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

Fai una grep nel tuo progetto per .global_position e .global_transform prima di pubblicare. Ogni occorrenza nei contenuti spaziali è un potenziale bug di drift. Questa classe di bug si presenta anche nel 3D tradizionale e nel multiplayer: errori di anchor e di ownership su una transform replicata producono esattamente lo stesso sintomo dell'"oggetto teletrasportato per alcuni client", ed è per questo che trattare le transform come locali al container piuttosto che come assolute è un'abitudine che vale la pena portare in qualsiasi progetto Godot in rete.

Verificare la Correzione

Per confermare che l'ancoraggio sia corretto:

1. Avvia la tua scena e annota la posizione della board.
2. Togli il dispositivo, aspetta 60 secondi, rientra nell'app.
3. La board dovrebbe apparire nella stessa posizione fisica relativa alla stanza, non allo stesso offset da dove ti trovi.
4. Ripeti con il dispositivo in un orientamento diverso: siediti, poi alzati.

Se va alla deriva, il tuo albero dei contenuti ha ancora riferimenti assoluti. Se salta ma rimane coerente dopo il salto, il container viene riposizionato e i tuoi contenuti lo seguono correttamente: è un comportamento previsto, non un bug.

Gestire l'Identità del Giocatore e lo Stato Persistente

Le app spaziali su Android XR sono app Android. Vengono sospese, riprendono, l'utente può avere più identità collegate sul dispositivo e i tuoi dati di salvataggio vivono nello stesso ecosistema di account di tutto il resto.

La modalità di fallimento è sottile: un giocatore gioca in modalità spaziale sugli occhiali, poi apre lo stesso gioco sul telefono. Se il tuo stato di salvataggio è locale al dispositivo, ora ha due mondi divergenti e nessun modo per riconciliarli. Risolvere questo non è un problema di rendering, ma di identità dell'account.

Farlo bene da soli significa implementare flussi di accesso, uno store di salvataggi lato server e — la parte che tutti sottovalutano — la gestione dei conflitti quando due dispositivi scrivono nello stesso slot di salvataggio. Un modello di lettura/scrittura revision-aware in cui il client confronta le versioni e risolve i conflitti esplicitamente è l'unica versione che sopravvive al contatto con utenti reali. Costruirlo da zero è un lavoro di diverse settimane; horizOn offre salvataggi cloud legati all'account con letture e scritture revision-aware esattamente per questo caso, insieme ad autenticazione via email, anonima, Google e Apple, così che la stessa identità del giocatore venga trasportata tra occhiali e telefono.

Qualunque backend tu usi, decidi la politica di conflitto prima di pubblicare. L'ultima scrittura vince distrugge silenziosamente i progressi. Chiedere al giocatore è meglio che perdere dati.

Best Practice per Pubblicare su XREAL AURA

1. Progetta per la luce ambientale. Testa ogni pannello UI all'aperto a mezzogiorno e in una stanza buia. Se il testo diventa illeggibile in uno dei due casi, alza il contrasto e aggiungi un contorno luminoso sottile invece di un'ombra scura: le ombre non servono a nulla su un display trasparente.
2. Mantieni i container piccoli e richiedibili. Un volume da 60cm è più facile da posizionare in modo affidabile per il sistema di uno da 2m. Presumi che ogni container possa andare perso in qualsiasi momento e scrivi il percorso di recupero per primo, non per ultimo.
3. Limita aggressivamente il tuo budget di rendering. Questi sono occhiali, non una GPU desktop. Punta a un frame time inferiore a 11ms (classe 90Hz) con l'anti-aliasing temporale disattivato a favore di MSAA, che costa meno alle risoluzioni spaziali.
4. Metti la UI nei pannelli, i contenuti nei volumi. Non combattere la logica di posizionamento del sistema per il testo. Riserva i volumi per elementi con profondità reale che il giocatore ispeziona da più angolazioni.
5. Verifica sul dispositivo prima di ogni milestone. L'editor sugli occhiali rende tutto questo economico. I risultati del simulatore non riveleranno anchor drift, problemi di luminanza o comportamenti di perdita dei container.

Passo Successivo

L'editor on-device è la vera notizia qui. Comprime il ciclo di iterazione spaziale da minuti a secondi, ed è la differenza tra mettere a punto un design e tirare a indovinare.

Inizia installando l'editor e l'app Gradle complementare su AURA, poi ricostruisci un piccolo progetto esistente come scena spaziale invece di partire da zero: emergeranno subito i problemi di ancoraggio e luminanza, su contenuti che già conosci. Da lì, aggiungi un container di volume 3D e un pannello UI e rendili entrambi stabili attraverso un ciclo di sospensione/ripresa. Una volta che regge, sei pronto a progettare per la piattaforma invece che contro di essa.

Se nella tua lista c'è lo stato persistente del giocatore tra dispositivi, horizOn gestisce il salvataggio cloud legato all'account con risoluzione dei conflitti lato client, così la tua sessione spaziale e la tua sessione su schermo piatto restano allineate.

---

Fonte: Pronti per XREAL AURA