Unreal Foliage, PCG und HISM Optimierungsleitfaden

Direkte Antwort

Der Leitfaden „Unreal Foliage, PCG und HISM-Optimierung“ sollte als kontrollierte Produktionsentscheidung verstanden werden, welche wiederkehrenden Inhalte instanziiert bleiben und welche Variation separate Actors oder Komponenten rechtfertigt. Definieren Sie den Eigentümer von Foliage-Typen, machen Sie hierarchisches Instancing beobachtbar, testen Sie PCG-Ausgaben unter der Ziel-Unreal-Version und Zielplattform, und bewahren Sie ein Fehler- und Rollback-Ergebnis auf. Dieser Leitfaden behandelt Foliage-Typen, hierarchisches Instancing, PCG-Ausgaben, Culling, Dichte-Skalierung, Kollision, Speicher; er behauptet nicht, dass ein einziger Editor-Durchlauf ein gepacktes, netzwerkfähiges oder plattformreifes Ergebnis beweist.

Mache die Entscheidung auf einem sauberen Checkout für einen anderen Entwickler wiederholbar. Dieser Artikel richtet sich an Weltbauer und Open-World-Teams, die Skalierung, Streaming, Navigation und physische Simulation verwalten. Er konzentriert sich auf den Produktionsvertrag rund um Foliage-Typen, hierarchische Instanziierungund PCG-Ausgaben. Es schließt bewusst lizenzierte Auslieferungsumgebungsanweisungen, nicht dokumentierte Engine-Garantien, private Projektimplementierungsdetails und Behauptungen aus, die nicht aus einem benannten Baseline-Zustand reproduzierbar sind.

Wichtige Erkenntnisse

• Behandle Foliage-Typen als ein eigenes, verantwortungsvolles Subsystem, nicht als isolierte Projektoption.
• Testen Sie hierarchisches Instancing unter den benannten Engine-, Build-, Projektmaterial- und Ziel-Runtime-Zuständen, die relevant sind.
• Nutze PCG-Ausgaben, um Erfolg, Drift, Unterbrechung und Fallback sichtbar zu machen.
• Öffnen Sie die Produktionsentscheidung erneut, wenn Instanzanzahlen maximiert werden, ohne Culling-Zellen, Draw Calls, Kollision, Speicher, Regeneration und Editierkosten zu messen.

Definieren Sie die Systemgrenze vor der Implementierung

Die erste Aufgabe besteht darin, Engine-Verhalten, Projektvorgaben und das gemessene Prüfartefakt zu trennen. Die offizielle Dokumentation von Epic Games beschreibt allgemeine Unreal Engine-Konzepte und unterstützte Verfahren. Eine Codebasis entscheidet weiterhin über Benennung, Eigentümerschaft von Zustand, Lebenszyklusdauer, Performance-Budgets, Testabdeckung und Freigabetore. Eine lokale Feststellung beweist nur die Kriterien, die tatsächlich geprüft wurden. Diese Ebenen getrennt zu halten macht den Beitrag zitierbar, ohne ein Beispiel zur universellen Zusage zu machen.

For unreal foliage pcg HISM-Optimierung, die Systemgrenze beginnt bei Foliage-Typen. Schreibe auf, wer sie erstellt, wer sie ändern darf, wann sie gültig wird und was sie ungültig macht. Ordne anschließend das hierarchische Instanziieren einer konkreten Quellbedingung und PCG-Ausgaben einem nachvollziehbaren Ergebniswert zu. Wenn keine besitzende Komponente oder kein beobachtbares Ergebnis benannt werden kann, ist das operative Design nicht skalierbar über Maps, Nutzer, Builds oder Gerätefamilien.

Ownership-Checkliste

• Verantwortliche Komponente der Foliage-Typen: protokolliere das Implementierungsmodul, die Objektinstanz, das besitzende Asset, die Service-Grenze oder Plattformkennung; schließe die Review-Frage mit einem Quellpfad oder einer Konfiguration plus Hinweisen zum Eigentumszeitraum ab.
• Autoren des hierarchischen Instanzierens: Protokolliere Trigger, Events, verknüpfte Systeme, Ausführungsreihenfolge und Entscheidungsverantwortlichen; schließe das Issue mit einem Trace, Run-Log, Debugger-Capture oder einer deterministischen Zustandsprüfung ab.
• Nachweis für PCG-Ausgaben: Dokumentieren Sie das akzeptierte beobachtbare Ergebnis, das Ressourcenlimit und den unzulässigen Zustand; schließen Sie den Vorgang mit wiederholtem Bestehen, Fehler und Wiederherstellung unter einer Basislinie ab.
• Außerhalb der Implementierungstiefe: Erfassen Sie nicht unterstützte Release-Branches, Plugins, Geräte und Produktionsannahmen; schließen Sie die Review-Frage mit einer ausdrücklich genannten Einschränkung und einem Rückbau-Trigger ab.

Wie Unreal-Foliage-, PCG- und HISM-Optimierung in einem Produktionsprojekt funktioniert

Trennen Sie dokumentiertes Engine-Verhalten von Titelpolitik und quantifizierten Verifikationsunterlagen auf Workstation-Ebene. Beginnen Sie mit Foliage-Typen als autoritärer Wahrheit. Die umgebenden Unreal-Systeme dürfen diese Wahrheit cachen, replizieren, rendern, serialisieren oder transformieren, aber bei jeder technischen Übergabe sollte ein klar definierter Vertrag gewahrt bleiben. Wenn die Übergabe von Hierarchical Instancing diese Verantwortungsgrenze überschreitet, erfassen Sie Datenform, Zeitverhalten, Schreib-Authority und Fehlerreaktion, statt sich auf eine implizite Editor-Konvention zu verlassen.

Die nächste Schicht sind PCG-Ausgaben. Mache sie an der Stelle nachvollziehbar, an der die Entscheidung getroffen wird, nicht erst nachdem ein Spielnutzer das beobachtete Problem bemerkt hat. Je nach Thema kann geeigneter überprüfbarer Nachweis ein Unreal Insights-Trace, eine Gameplay-Debugger-Kategorie, ein Netzwerkmitschnitt, ein AutomationTool-Trace-Log, ein geprüftes Asset-Audit, ein generiertes Manifest, ein Profiler-Capture oder eine kleine wiederholbare Testmap sein. Die Diagnostik ist weniger wichtig als die Bewahrung der Bedingungen und der Autorität hinter dem Ergebnis.

Verbinden Sie Culling abschließend mit einem Akzeptanzbudget. Ein technischer Bereich kann funktional korrekt sein und dennoch scheitern, weil er zu viel Frame-Zeit, Speicher, Bandbreite, Build-Zeit, Paketgröße, Aufwand der Implementierungsverantwortung oder Wiederherstellungszeit verbraucht. Wenden Sie mindestens ein normales Szenario und ein Vertragsgrenz-Szenario an, das der Produktionsskala ähnelt. Extrapolieren Sie nicht aus einer leeren Vorlagen-Codebase, ohne diese Einschränkung zu benennen.

Themen-spezifisches Betriebsmodell

Für diesen Leitfaden beginnen Sie damit, den für die Aktivierung zuständigen Verantwortlichen für World Partition, Datenebene, Streaming-Quelle, Physikszene oder Content zu bestimmen. Der erste Kontrollpunkt sind Foliage-Typen, während Hierarchical Instancing und PCG-Ausgaben das Lieferpaket beschreiben, das sichtbar bleiben muss. Lassen Sie nicht zu, dass ein bequemes Besitzobjekt, eine rein editorseitige Vorschau oder eine nachgelagerte Präsentationsschicht versehentlich zur zweiten autoritativen Quelle wird. Schreiben Sie die Ownership-Einschränkung neben die Projektrevision, sodass die Teardown- und Neustartantwort mit dem Betriebsdesign überprüft werden kann.

Der praktikabelste beobachtbare Nachweis hier sind Streaming-Logs, Zell- und Actor-Zustände, Speichertraces, Kollision- oder Navigationsprüfung sowie Traversal-Captures. Wenden Sie dieses Prüfartefakt auf PCG-Ausgaben an, bevor Sie das Culling optimieren. Ein bestandener Befund muss die Eingangsbedingung, den beobachteten Übergang, das Ausgabe-Artefakt und die Build-Identität benennen. Wenn ein Tool nicht die wichtige Eigentümer-Komponente oder das Zeitverhalten anzeigen kann, hängen Sie engere Instrumentierung an der Systemgrenze anstatt Korrektheit aus der ausgelieferten visuellen oder auditiven Wahrnehmung abzuleiten.

Üben Sie Teleport, Entladen und erneutes Laden, Origin-Shift, Server-Travel, Verlust der Streaming-Quelle und Physik-Neusimulation. Diese Fälle sind besonders wichtig, da die definierende Schwachstelle dieser Seite darin besteht, Instanzanzahlen zu maximieren, ohne die Culling-Zellen, Draw Calls, Kollision, Speicherverbrauch, Regeneration und Editierkosten zu messen. Beenden Sie beim ersten Zustand, der der beabsichtigten Authority widerspricht, und speichern Sie dessen Trace oder Laufprotokoll. Weisen Sie nach, dass ein erneuter Versuch oder eine Rücknahme veraltete Laufzeitressourcen und doppelte Arbeit entfernt. Eine Erweiterung von Spielinhalt oder Hardware-Zielen vor vorhersehbarem Fallback verdeckt die Kante des kausalen Vertrags.

Die repräsentative Abnahme sollte geladene Zellen und Actors, Speicher, Traversierungs-Latenz, Physik-Schrittkosten, Proxy-Kosten und Paketgröße umfassen. Wähle nur die Maße aus, die sich auf die Optimierung von Unreal Foliage PCG HISM beziehen, gib deren Einheiten und das Stichprobenfenster an und halte den Materialausschnitt des Spiels konstant. Die technische Entscheidung bleibt, welche wiederholte Inhalte instanziert bleiben und welche Variation separate Actors oder Komponenten rechtfertigt. Sie wird erst geschlossen, wenn der gewählte Pfad, die abgelehnte Alternative, bekannte Einschränkungen und der Wiederöffnungsfall Teil des Lieferpakets sind.

Entscheidungsrahmen

Die Kernentscheidung lautet, welche wiederkehrenden Inhalte instanziiert bleiben und welche Variation separate Actors oder Komponenten rechtfertigt. Verlassen Sie sich auf die untenstehende Matrix, damit diese Entscheidung an Teammitglied und Produktionsauswirkung gebunden ist statt an Funktionspräferenz.

Entscheidungsfälle

• Schreibe Kontrolle und Lebenszyklus spezifisch auf: Behalten Sie die kleinste Architektur bei, die Foliage-Typen klar darstellt. Verlangen Sie die Überprüfung von Initialisierung, Mutation, Teardown und Neustart. Überdenken Sie die Lösung, wenn ein anderer Zustandsinhaber beginnt, denselben Zustand zu schreiben.
• Mehrere Hilfsmittel scheinen das Produktionsproblem zu lösen: Vergleichen Sie sie über einen repräsentativen Hierarchical-Instancing-Ablauf mit demselben Asset-Satz, derselben Revision, derselben Zielplattform und demselben Akzeptanztest. Überdenken Sie die Entscheidung, wenn eine Implementierungswahl von versteckten Titel- oder Delivery-Umgebungsannahmen abhängt.
• Der Standardpfad funktioniert: Hängen Sie ungültige, Unterbrechungs-, Neustart- und Skalierungstest-Segmente an. Verlangen Sie ein Problemsignal sowie eine saubere Wiederherstellung. Überdenken Sie die Lösung, wenn der Fallback eine manuelle Reparatur erfordert oder einen veralteten Zustand hinterlässt.
• Unterschiede bei Unreal Engine-Version oder Gerätefamilien-Support: Isolieren Sie den nicht verfügbaren Pfad hinter einer eindeutig definierten Ownership-Grenze. Behalten Sie das Dokumentationsdatum, das Build-Ergebnis und den Fallback bei. Überdenken Sie die Lösung, wenn sich durch den Fallback das von Teammitgliedern protokollierte Laufzeitverhalten oder die Ressourcenkosten ändert.

Machen Sie die Auswahl für einen anderen Implementierer auf einem sauberen Checkout reproduzierbar. Eine gute Produktionsentscheidung ist reversibel. Dokumentieren Sie die Begründung für die gewählte Richtung, den beobachtbaren Nachweis dafür und die Bedingung, die sie aufhebt. Diese Dokumentation ist wertvoller als eine lange Fähigkeitsliste, weil sie Personalwechseln und Engine-Upgrades überdauert.

Implementierungs- und Validierungs-Workflow

1. Baseline einfrieren. Friere den Unreal-Engine-Patch, die Projekt-Revision, Plugins, Zielplattform, Build-Konfiguration und den realistischen Content-Ausschnitt ein. Schreibe die erforderliche Beobachtung für Foliage-Typen auf, bevor du die interne Einrichtung änderst.
2. Verantwortung zuweisen. Nennen Sie den Zustands- und Laufzeit-Lebenszyklus-Besitzer für hierarchisches Instancing. Erfassen Sie, welches Projektmodul, welche Objektinstanz, welcher Provider, welches importierte Asset oder welche Runtime-Schicht es verändern kann und welche Schichten es nur beobachten oder anzeigen.
3. Instrumentierungsreview-Artefakt. Stellen Sie PCG-Ausgaben über einen passenden Erfassungs-, Trace-Log-, Debugger-Kategorie-, Profiler-, Manifest- oder deterministischen Diagnoseprüfschritt für das Subsystem bereit. Verlassen Sie sich nicht auf einen letzten Screenshot als einziges beobachtbares Beweismittel.
4. Testunterbrechung. Üben Sie den erwarteten Pfad mit festen Eingaben und führen Sie ihn anschließend erneut aus mit einer unzulässigen Eingabe, einer Unterbrechung und einem Neustart oder Reconnect. Behalten Sie über jeden Lauf dieselben Release-Checks bei.
5. Repräsentative Skalierung quantifizieren. Profile Culling anhand repräsentativer Produktionsdaten und Hardware. Erfassen Sie Messeinheiten, Zeitfenster, Teststichprobenbedingungen und Build-Identität, damit ein späterer Vergleich dieselbe Grundlage nutzt.
6. Veröffentlichen Sie die Teamübergabe. Verpacken Sie das Urteil als Team-Übergabe: geänderte Dateien, Voraussetzungen, Reproduktionsbefehl, erwarteter Nachweis, bekannte Einschränkung, Besitzer und die Bedingung, die den Rückbau oder erneute Untersuchung auslöst.

Diese Arbeitsreihenfolge trennt Absichtlich Setup, Integration, Beobachtung und Akzeptanz. Wenn ein Test fehlschlägt, kehren Sie zur frühesten Ownership-Grenze zurück, die nicht mehr mit dem beobachtbaren Beweis übereinstimmt. Ändern Sie nicht mehrere Projektoptionen und behalten dann nur den letzten funktionierenden Screenshot; damit geht die Kausalitätskette verloren, die ein anderer Entwickler benötigt.

Validierungsmatrix

Erforderliche Validierungsausschnitte

• Baseline: Verlassen Sie sich auf einen bekannten Change-Set und minimales Projektmaterial in Zielskala. Erfassen Sie Besitzer, Übergang, Ausgabe und Zeitverhalten. Bestehen, wenn das Ergebnis ohne versteckte nicht automatisierte Schritte reproduzierbar ist; andernfalls bewahren Sie die erste kausale Spur auf und stoppen Sie die Ausweitung des Verantwortungsbereichs.
• Fehlerhafter Eingabewert: Verlassen Sie sich auf eine fehlende, fehlerhafte, nicht autorisierte oder nicht verfügbare Anforderung. Erfassen Sie eine unmissverständliche Ablehnung und einen unveränderten autoritativen Zustand. Bestehen Sie, wenn kein Crash, kein veralteter Zustand und kein stiller Erfolg vorliegt; verbessern Sie andernfalls die Qualitätsprüfung an der verantwortlichen Systemgrenze.
• Interruption: Führen Sie Travel, Abbruch, Disconnect, Teardown oder Build-Abbruch durch, soweit zutreffend. Erfassen Sie Zustandsbereinigung und Rückgabeweg. Bestehen Sie, wenn das Produktionssystem ohne manuelle Nachbesserung in einen bekannten Zustand zurückkehrt; dokumentieren Sie andernfalls Abbruch, Timeout oder Transaktions-Fallback-Revision.
• Scale: Wählen Sie gemessene Actors, Art Assets, Nutzer, Frames, Jobs oder Geräte aus. Erfassen Sie die Kosten mit Einheiten und Testbeispielen. Bestehen, wenn der vereinbarte Zielkorridor Reserven hat; reduzieren Sie andernfalls den Umfang oder ändern Sie die Architektur vor dem Feinschliff.
• Upgrade: Wählen Sie den Ziel-Engine-Patch, den Plugin-Satz oder die Gerätefamilie-Toolchain. Vergleichen Sie Ausgabedateien vor und nach der Änderung. Bestehen, wenn Verhalten und Akzeptanzgrenze innerhalb der Grenzen bleiben; stellen Sie andernfalls das vorherige Baseline wieder her und dokumentieren Sie die Inkompatibilität.

Für unreal foliage pcg hism optimization können aussagekräftige Zahlen Millisekunden pro Frame, Megabytes, replizierte Bytes, Kochzeit, Paketgröße, gleichzeitige Objekte, aktive Stimmen, Shader-Permutationen, geladene Zellen oder Rückgabezeit in Sekunden sein. Verwenden Sie nur Messungen, die das tatsächliche Subsystem bereitstellt. Wenn ein Parameter nicht profiliert wurde, kennzeichnen Sie ihn als unbekannt, statt die Seite mit einer Schätzung zu füllen.

Fehlermuster und Wiederherstellung

Ownership Drift

Verantwortungsdrift tritt auf, wenn Foliage-Typen aus mehreren Ebenen ohne kontrollierte Präzedenz- oder Änderungslogik verändert werden können. Das sichtbare beobachtete Problem kann zufällig wirken, doch die Ursache liegt meist in einem undokumentierten mutierenden Eigentümer oder Lebenszyklus. Binden Sie zuständigkeitsspezifische Verifizierungsnachweise an, lehnen Sie ungültige Schreibvorgänge ab und wiederholen Sie dieselbe Schrittfolge nach Travel, Reload, Reconnect oder Teardown.

Versions- und Konfigurationsdrift

Editor-Standardeinstellungen, Plugins, Build-Targets, Zielplattform-Servicegrenzen und Spieleprojekteinstellungen ändern sich zwischen Engine-Versionen und Maschinen. Speichern Sie die festgelegte Versionslinie und das Laufzeitsetup neben dem Verifizierungsmaterial. Ein funktionierendes UE 5.8-Beispiel darf nicht als Beweis für einen älteren Branch oder ein anbieter-spezifisches Code-Plugin gelten, sofern diese Kombination nicht tatsächlich getestet wurde.

Skalierung hinter einem Happy Path verbergen

Hierarchical Instancing kann mit einem Actor, Asset, Teammitglied oder Runtime-Hardware funktionieren, während die Ressourcenkosten und Verarbeitungsreihenfolge bei repräsentativer Skalierung versagen. Erhöhen Sie eine Dimension nach der anderen und dokumentieren Sie die erste gemessene Toleranz- oder Korrektheitsgrenze. Bewahren Sie die Testproduktionsdaten auf, damit spätere Arbeiten denselben Fehler messen statt eine neu erfundene Benchmark.

Wiederherstellung, die auf manuelle Reparatur angewiesen ist

Betrachten Sie den Betriebsweg erst dann als abgeschlossen, wenn Diagnoseprotokoll und sichere Rückführung erhalten geblieben sind. Das typische Risiko dieses Themas ist die Maximierung der Instanzanzahl ohne Messung von Culling-Zellen, Draw Calls, Kollision, Speicher, Regeneration und Editierkosten. Eine funktionierende Wiederherstellung stellt den autoritativen Zustand wieder her, gibt Produktionsressourcen frei, verhindert doppelte Callbacks oder Berechtigungen und hinterlässt ausreichend Prüfartefakt, um den Ablauf zu erklären. Wenn ein Entwickler generierte Daten löschen oder mehrere Tools ohne dokumentierte Begründung neu starten muss, ist der Workflow nicht produktionstauglich.

Versions-, Plattform- und Nachweisgrenzen

Diese Seite wählt die aktive UE-5.8-Doc-Oberfläche als ihren zeitlich befristeten Referenzpunkt. Epic Games kann versionsabhängige Zustände, Voreinstellungen, Plugin-Paketierung, APIs, Plattformunterstützung und empfohlene Produktionsabläufe ändern. Prüfen Sie die veröffentlichte Anleitung zur Release-Branch-Auswahl und die Release Notes, bevor Sie Einstellungen in eine andere Entwicklungslinie übernehmen. Für delivery-umgebungsbezogene Arbeiten ersetzen veröffentlichte Unreal-Leitfäden nicht lizenzierte Plattformdokumentation oder Zertifizierungszugänge.

Der Artikel liefert eine Validierungsmethode, nicht die Behauptung, dass SEELE AI oder dieses Repository jedes plattformnahes Szenario ausgeführt hat. Wo sich offizielle Erstanbieter-Dokumentation und Codebasis-Prüfmaterial unterscheiden, dokumentiere beides und beschränke die Schlussfolgerung auf den getesteten Titel. Verberge den Unterschied nicht, indem du einen Prototyp, eine Editor-Vorschau oder eine generierte Illustration als Paket-Game-Fundstelle darstellst.

Checkliste für Teamübergaben

• Spezifischer Unreal Engine-Release-Branch, Projektrevision, Plugins, Zielplattform und ausgewählte Build-Optionen.
• Benannte verantwortliche Ebene für Foliage-Typen und die Schnittstelle zum hierarchischen Instancing.
• Reproduktionsaufgaben für Standard-, ungültige, Unterbrechungs-, Wiederherstellungs- und Skalierungsszenarien.
• Logs, Traces, Manifeste, Screenshots oder Profiler-Aufzeichnungen mit Build-Identität und Zeitstempeln.
• Profiliertes Abnahme-Limit für PCG-Ausgaben und die Produktionsrestriktionen dahinter.
• Nicht unterstützte Testausschnitte, eingeschränkte Abhängigkeiten, Lizenzsystemgrenzen und bekannte Unbekannte.
• Wiederherstellungspfad-Ausführungsanweisung oder Revision plus das Kriterium, das es erfordert.

Ein anderer Programmierer sollte die Feststellung aus diesem Handoff reproduzieren können, ohne lokale Build-Worker-Pfade oder eine mündliche Erläuterung zu benötigen. Wenn der erste fehlerhafte Zustand nicht identifizierbar ist, braucht das Diagnosepaket Verbesserungen, selbst wenn die Funktion zu funktionieren scheint.

SEELE AI-Übergabebereich

SEELE AI kann ein Team dabei unterstützen, eine Szenenrichtung, Interaktionsschleife, Produktionsdaten-Zusammenfassung, Kamerahaltung oder einen Testplan zu vergleichen, bevor tiefere Unreal-Produktionsarbeit beginnt. Dieser vorgelagerte Prototyp kann die beabsichtigte Spielerwahrnehmung klären und die Unschärfe im Integrations-Backlog reduzieren. Es handelt sich nicht um eine UE-native Engine-Integration oder einen Beweis-Worksurface.

SEELE AI kann ein natives Unreal 5 Spiel generieren, es im Browser in einer Vorschau anzeigen, optimieren und paketieren und ein herunterladbares Spiel oder gepacktes Build für externe Veröffentlichung oder bezahlte Seele-Spiele bereitstellen. Verkäufe sind nicht garantiert.

Offizielle Quellen und verwandte Leitfäden

Fahren Sie mit den [Unreal Engine Worldbuilding, Virtual Production, Platforms, and Operations Guides](/resources/blogs/unreal-engine-worldbuilding-virtual-production-platforms-guides-library) fort, um diese technische Entscheidung mit ihren Voraussetzungen, verwandten Runtime-Ebenen, Abhängigkeiten der Qualitätsprüfung und Release-Übergaben zu vergleichen. Das Hub ist der kanonische Index für diesen Themenverbund und verlinkt jeden fokussierten Leitfaden in der Folge.

• Verwendung von PCG mit World Partition in Unreal Engine | Unreal Engine 5.8 Dokumentation | Epic Developer Community — erstanbieterbezogene Referenz, die nur für das Verhalten, die Engine-Version oder den Produktionsablauf verwendet wird, den sie explizit dokumentiert.
• World Partition - Hierarchisches Level of Detail in Unreal Engine | Unreal Engine 5.8 Dokumentation | Epic Developer Community — First-Party-Referenz nur für die Antwort, den Release-Branch oder den Produktionsablauf, den sie ausdrücklich dokumentiert.

Unreal Engine ist ein eingetragenes Warenzeichen von Epic Games. SEELE AI ist unabhängig und diese Seite impliziert keine Förderung, Partnerschaft oder von Epic Games verifizierte UE-native Integration durch Unreal Engine.