Vision Pro rendert stereoskopisch auf zwei Micro-OLED-Displays (je ca. 3.660 × 3.200 Pixel effektiv). Der Fill-Rate- und GPU-Aufwand liegt damit über dem eines klassischen Mobilgeräts. Polycount-Vorgaben aus Desktop- oder Render-Pipelines sind nicht ohne Anpassung übertragbar.

Beide Generationen nutzen 16 GB Unified Memory und den R1-Chip für Sensorfusion. Für Asset-Budgets gilt: auf M2 konservativ planen, auf M5 zusätzlichen Headroom für Geometrie, Texturen und Effekte nutzen.

Für den Import werden USDZ sowie GLB/GLTF (unkomprimiert) unterstützt – inklusive Materialvarianten-Schaltung. FBX-Dateien können importiert werden; für tilende Texturen muss die Kennzeichnung TILEx.x im Objektnamen enthalten sein. OBJ, STL, PLY, 3MF und DAE sind ebenfalls importierbar, jedoch mit eingeschränktem Funktionsumfang bei Materialien, Texturen, Animationen und weiteren Szenendaten.

Apple unterscheidet zwischen Shared Space (Fenster, Volumen) und Full Space (immersiv). Die zulässige Geometriemenge hängt vom Darstellungskontext ab:

Draw Calls stellen eine wesentliche Beschränkung für XR-Anwendungen auf visionOS dar – die Limits liegen deutlich unter denen von Desktop-Anwendungen. Die tatsächliche Performance hängt von mehreren Faktoren ab und kann von Szene zu Szene variieren.

Alle Vorgaben sind Richtwerte – die Performance einer Szene setzt sich aus Polycount, Texturauflösung, Draw Calls, Overdraw, Lichtquellen und weiteren Faktoren zusammen. Grundsatz: so viel wie nötig, so wenig wie möglich.

Achte auf korrektes Padding und gleichmäßige Texel Density. Normal Maps sollten als Tangent-Space Normalmaps mit OpenGL-Konvention vorliegen. Texturen sollten in Pixelabmessungen einer Zweierpotenz (Power of Two) entsprechen.

• Gebackene Materialien pro Objekt: 2048² oder 4096²
• Tiling-Textures: 256²–512²
• Die optimale Auflösung hängt von der Anzahl der Texturen in der Szene ab

Eine möglichst geringe Verzerrung der UVs und eine gleichmäßige Texel Density sind besonders wichtig. So bleibt die Detailqualität über das gesamte Modell konsistent – einzelne Bereiche wirken weder unscharf noch übermäßig detailliert.

Für den Export nach visionOS müssen alle Materialien auf die unterstützten PBR-Maps überführt werden: Albedo (Color), Roughness, Metallic, Normal (OpenGL), Opacity sowie optional Ambient Occlusion oder Emission. Abweichungen hiervon werden oft nicht korrekt exportiert und können zu fehlerhafter Darstellung führen.

Anforderungen an HDR- und OpenEXR-Umgebungsdateien für HDRI Custom Map.

Bevorzugtes Format: Radiance HDR

• Dateiformat: .hdr
• Projektion: Equirectangular
• Seitenverhältnis: 2:1
• Empfohlene Auflösung: 4096 × 2048 Pixel
• Farbraum: Lineare HDR-Farbwerte

Alternatives Format: OpenEXR

• Dateiformat: .exr
• Bildstruktur: Single-part, Flat Scanline
• Kanäle: Freistehende Kanäle R, G und B
• Pixeltyp: Half oder Float, linear
• Kompression: ZIP oder PIZ
• Projektion: Equirectangular
• Seitenverhältnis: 2:1
• Empfohlene Auflösung: 4096 × 2048 Pixel

Inhaltliche Anforderungen

• Die Datei muss eine vollständige, nahtlose 360°-Umgebung mit Himmel und Boden enthalten.
• Benutzeroberflächen, Logos, Wasserzeichen oder Text-Overlays dürfen nicht in das Bild eingebettet sein.
• Eine separate Alpha-Maske ist nicht erforderlich.

Alle Varianten werden für die Bedienung auf denselben Runtime- und UI-Flow abgebildet. App-spezifische Hierarchie-Varianten werden über *_SWITCH erkannt; native Formatvarianten werden beim Import entsprechend angebunden.

*_SWITCH → Variant A / Variant B / Variant C

GLB / glTF – nativer Materialvarianten-Weg

GLB bzw. glTF unterstützt Materialvarianten nativ über die ratifizierte Khronos-Erweiterung KHR_materials_variants. Die Variantennamen werden im glTF-Asset definiert; an den Mesh-Primitives wird hinterlegt, welches Material zu welcher Variante gehört. Die Geometrie kann dabei gemeinsam genutzt werden und muss für reine Materialvarianten nicht dupliziert werden.

presentAR liest diese Varianten beim Import aus und überführt sie für die Bedienung in den gemeinsamen Varianten- und UI-Flow. Für echte Geometrievarianten bleibt zusätzlich die presentAR-spezifische SWITCH-Hierarchie möglich.

Beispiel: Chair → KHR_materials_variants → Red | Blue | Leather

USDZ – nativer Weg

USDZ ist das Paketformat; das Variantensystem selbst stammt aus OpenUSD. VariantSets sind der native USD-Mechanismus für umschaltbare Alternativen eines Prims. Sie sind nicht auf Materialien beschränkt: Eine Variante kann beispielsweise Materialbindungen, Geometrie, Properties oder komplette Unterhierarchien verändern.

Beispiel: Chair → VariantSet "Material" → Red | Blue | Leather

Für native USDZ-Varianten ist daher keine presentAR-spezifische Textur-Namenskonvention erforderlich. Die bisherige Erkennung über Textur-Suffixe kann optional als Legacy-/Fallback-Weg erhalten bleiben.

Pro Datei darf nur ein Character-Rig verwendet werden. Jede Animation muss als eigene Action erstellt und anschließend in einem NLA-Track organisiert werden.