Technische Details

Systemarchitektur, Persistenz und Asset-Management in ARIZON

Die technische Architektur des ARIZON-Prototypen basiert auf einer engen Verzahnung von hardwareseitigen Tracking-Algorithmen und einer datengetriebenen Softwarestruktur innerhalb der Engine. Um eine stabile Verankerung digitaler Inhalte im urbanen Raum zu gewährleisten, greift das System auf spezialisierte Persistenz- und Lokalisierungsmechanismen zurück.

1. Funktionsweise der Meta Spatial Anchors

Zur sitzungsübergreifenden Speicherung virtueller Objekte nutzt ARIZON lokale Spatial Anchors (Raumanker). Im Gegensatz zu systemweiten Szenenankern, die permanente Geometriedaten der Umgebung speichern, sind diese Raumanker app-spezifisch: Sie verbleiben im geschützten Laufzeitkontext der Anwendung und werden erst beim Starten der App dynamisch initialisiert.

● Das Prinzip des World-Locking:

Jeder instanziierte Raumanker erhält vom System eine eindeutige Identifikationsnummer, eine sogenannte Universally Unique Identifier (UUID). Diese UUID dient dem Headset als Referenzschlüssel, um die dreidimensionalen Koordinaten der virtuellen Welt präzise mit den markanten Merkmalen der physischen Umgebung abzugleichen.

● Laufzeit-Interaktionen:

Innerhalb der Anwendung unterstützen die Anker den vollständigen Zyklus der Objektmanipulation (CRUD-Prinzip). Sie können zur Laufzeit flexibel generiert, im Raum transformiert (verschoben und rotiert) oder dauerhaft aus der Datenbank gelöscht werden.

2. ARIZON Loading Order (Initialisierungs-Hierarchie)

Der Startprozess und die logische Verknüpfung der Softwarekomponenten folgen einer strikt hierarchischen Lade-Reihenfolge. Diese Befehlskette stellt sicher, dass alle Subsysteme und Abhängigkeiten korrekt aufgelöst werden:

● Engine & GameInstance:

Nach der Initialisierung der Engine startet die GameInstance. Da diese komponentenübergreifend über die gesamte Laufzeit hinweg existiert, speichert sie den globalen Systemstatus – insbesondere die aktive Nutzerrolle (Editor/Creator-Modus versus Betrachter/User-Modus).

● LoadLevel & GameMode:

Das Laden des Levels stößt den Lebenszyklus (Lifecycle) der zentralen Akteure (Actors) an. Hierbei wird der BP_PlayerPawn instanziiert, welcher die Bewegungskomponenten und die Interaktionslogik des Nutzers verwaltet.

● Hardware-Abstraktion (MRUK & OculusXR):

Parallel importiert der MRUKAnchorActorSpawner die physischen Raumdaten des Headsets, um exakte Kollisionen zwischen virtuellen Objekten und realer Geometrie zu berechnen. Zeitgleich übernimmt der OculusXRSceneActor das hardwarenahe Management der UUIDs und kommuniziert direkt mit der Tracking-Schnittstelle der Brille.

● Manager- und Asset-Ebene:

Der BP_AnchorManager übernimmt anschließend die Koordination der persistenten Daten. Er initiiert das Spawnen der BP_AnchorActor-Knotenpunkte, welche wiederum die finalen visuellen Assets (BP_SpawnActor) aufrufen. Eine globale Lichtquelle (SkyLight) schließt den Ladevorgang ab und berechnet die finale

3. Funktionsweise des BP_AnchorManager

Der BP_AnchorManager bildet das funktionale Herzstück der Datenserialisierung. Er steuert sowohl das Auslesen gespeicherter Zustände als auch das Sichern modifizierter Szenen.

Der Ladevorgang (Deserialisierung)

1. Dateiabfrage:

Das System sucht im lokalen Verzeichnis unter Content/SaveGames/ nach der Datei SaveGame.json. Diese Datei enthält den kompletten Zustand der Szene: UUIDs, Transformationsdaten (Position, Rotation), Skalierungswerte, Objekttypen, Objektnamen sowie spezifische Metadaten (z. B. redaktionelle Texte für Info-Tafeln oder Nutzerberechtigungen).

2. Daten-Parsing:

Mittels einer Schleife (For Loop) wird das Feld Anchors innerhalb der JSON-Datei ausgelesen. Die extrahierten Werte und UUIDs werden temporär im Arbeitsspeicher gecacht und anhand ihres Objekttyps semantisch geordnet.

3. Hardware-Abgleich:

Der Manager übergibt die lokalen UUID-Caches an den OculusXRSceneActor. Das Headset sucht daraufhin in der physischen Umgebung nach den korrespondierenden Raumankern.

4. Instanziierung:

Sobald das System die Anker lokalisiert hat, wird an den entsprechenden Koordinaten ein BP_AnchorActor erzeugt. Dieser gleicht seine UUID mit den JSON-Daten ab und fordert über die zentrale Datentabelle DT_SpawnActors das spezifische visuelle Modell an. Ist der Eintrag verifiziert, wird das finale Objekt (BP_SpawnActor) erzeugt und hierarchisch an den Anker gekoppelt.

Der Speichervorgang (Serialisierung)

Der Speichervorgang arbeitet ereignisgesteuert (Event-driven). Sobald eine Person im Creator-Modus ein Objekt platziert, verschiebt oder editiert, registriert das System diese Transformation und löst im BP_AnchorManager das Event SaveAnchors aus. Der Manager scannt die aktive Szene, erfasst die modifizierten Parameter aller BP_AnchorActors und schreibt die aktualisierten Datensätze konsistent in die SaveGame.json zurück.

4. Integration neuer Asset-Typen (Datengetriebene Erweiterung)

Das System nutzt ein datengetriebenes Entwurfsmuster (Data-driven Design). Um neue virtuelle Inhalte in ARIZON einzupflegen, werden diese als Subklassen der Basisklasse BP_SpawnActor angelegt und in der zentralen Datentabelle DT_SpawnActors registriert. Das Framework stellt vier spezialisierte Kind-Klassen zur Verfügung:

5. Technologischer Ausblick: Von lokalen zu geteilten Räumen

In der aktuellen Entwicklungsstufe operiert das ARIZON-System auf Basis isolierter, lokal auf dem Endgerät gespeicherter Raumanker. Diese Architektur ist für präzise Single-Player-Anwendungen im urbanen Raum optimiert.

Die Roadmap sieht eine Migration zu einer servergestützten Architektur unter Verwendung von Shared Spatial Anchors vor. Durch die Auslagerung der Raumanker in eine zentrale Cloud-Infrastruktur können die Lokalisierungsdaten simultan von mehreren Head-Mounted Displays synchronisiert und abgerufen werden. Diese technologische Transformation ermöglicht eine exakte räumliche Koinzidenz: Mehrere Nutzende können zeitgleich am selben physischen Ort interagieren und teilen eine absolut konsistente, synchrone Mixed-Reality-Erfahrung (Multi-User Co-presence).