Unreal DMX- und Virtual-Camera-Leitfaden

Direkte Antwort

Der Unreal DMX- und Virtual Camera Guide sollte als kontrollierte Produktionsentscheidung über das Abbilden welcher externen Steuersignalquelle auf welche Engine-Eigenschaft erfolgt und wie das Mapping protokolliert und wiederhergestellt wird, behandelt werden. Definieren Sie den Besitzer der DMX-Bibliotheken, machen Sie Fixtures nachvollziehbar, testen Sie Patches unter der Ziel-Unreal-Version und Plattform, und bewahren Sie ein Ergebnis für Ausfall und Rollback auf. Dieser Guide behandelt DMX-Bibliotheken, Fixtures, Patches, Protokolle, Virtual Cameras, Tracking, Recording, Operator Controls; er behauptet nicht, dass ein Editor-Lauf einen paketierten, vernetzten oder plattformbereiten Zustand beweist.

Legen Sie Zustandsinhaber und nachvollziehbaren Nachweisweg fest, bevor Sie Implementierungsdetails ändern. Dieser Artikel richtet sich an Cinematic- und Virtual-Production-Teams, die Kameras, Zeitplan, Farbe, Displays und aufgezeichnete Diagnoseprotokolle koordinieren. Er konzentriert sich auf die Produktionssystemgrenze rund um DMX-Bibliotheken, fixturesund patches. Er schließt bewusst vertrauliche Plattformanweisungen, nicht dokumentierte Engine-Garantien, private Projektimplementierungsdetails und Behauptungen aus, die sich nicht aus einer benannten Basislinie reproduzieren lassen.

Wichtige Erkenntnisse

• Behandeln Sie DMX-Libraries als ein eigens verwaltetes Subsystem, nicht als isolierte Einstellung.
• Teste Fixtures unter exakt den Engine-, Build-, Asset-Set- und Bereitstellungsumgebungszuständen, die relevant sind.
• Wenden Sie Patches an, damit Erfolg, Drift, Unterbrechung und Wiederherstellung aufgezeichnet werden.
• Öffnen Sie die Entscheidung erneut, wenn Sie Geräte verbinden, bevor Sie Adressierung, Einheiten, Koordinatenräume, Ratenbeschränkungen und sicheres Fallback-Verhalten festgelegt haben.

Definieren Sie die Systemgrenze vor der Implementierung

Die erste Aufgabe besteht darin, Engine-Verhalten, Produktspezifische Richtlinien und quantifizierte Diagnoseprotokolle zu trennen. Die Epic Games-Dokumentation beschreibt veröffentlichte Unreal-Engine-Konzepte und unterstützte Ausführungswege. Ein Codebestand entscheidet weiterhin über Benennung, Eigentum, Lebenszyklusdauer, Performance-Budgets, Testabdeckung und Freigabegates. Ein lokaler Output belegt nur die tatsächlich ausgeübten Situationen. Diese Ebenen getrennt zu halten macht den Artikel zitierbar, ohne ein Beispiel in ein universelles Versprechen zu verwandeln.

For unreal dmx virtuelle Kamera, die Besitzgrenze beginnt bei DMX-Bibliotheken. Schreibe auf, wer sie erstellt, wer sie ändern darf, wann sie als gültig gilt und was sie ungültig macht. Leite von dort aus die Fixtures zu einem konkreten Eingangs-Messwert und Patches zu einem prüfbaren resultierenden Wert. Wenn keine Autorität oder kein beobachtbares Ergebnis benannt werden kann, ist das operative Design nicht für Skalierung über Karten, Benutzer, Builds oder Bereitstellungsumgebungen vorbereitet.

Ownership-Checkliste

• Verantwortliche Ebene der DMX-Libraries: Protokolliere das Modul, die Objektinstanz, das Kunst-Asset, die Service-Grenze oder das Plattformkonto; schließe die Prüfung mit einem Quellpfad oder Laufzeit-Setup sowie Laufzeit-Lebensdauernotizen ab.
• Schreiber von Fixtures: Nehmen Sie Quellbedingungen, Laufzeitereignisse, benötigte Komponenten, Ereignisreihenfolge und autoritativen Besitzer auf; schließen Sie die Prüfung mit einer Capture, einem Trace-Log, einem Debugger-Capture oder einer vorhersehbaren Inspektion ab.
• Nachweis für Patches: Protokolliere das erwartete beobachtbare Ergebnis, das Zielbudget und den nicht unterstützten Zustand; schließe die Entscheidungsaufforderung mit wiederholtem Bestand, Ausfall und Reparaturpfad unter einer Quellrevision ab.
• Außerhalb der Arbeitsschnittstelle: Protokolliere nicht unterstützte Release-Branches, Plugins, Geräte und Produktionsannahmen; schließe den Entscheidungsaufforderung mit einer klaren Einschränkung und einem Rollback-Trigger ab.

Wie Unreal DMX und Virtual Camera in einem Produktionsprojekt funktionieren

Nutzen Sie eine repräsentative Teilschicht, damit Kosten, Korrektheit und Ablauflogik der Arbeitsabfolge vergleichbar bleiben. Beginnen Sie mit DMX-Bibliotheken als Wahrheitensource. Die umgebenden Unreal-Technikbereiche können diese Wahrheit cachen, replizieren, rendern, serialisieren oder transformieren, aber jedes Auslieferungspaket sollte einen lesbaren Vertrag erfassen. Wenn der technische Handover der Fixtures diese Vertragsgrenze überschreitet, erfassen Sie Datenform, Zeitverhalten, Autorität und Fehlerreaktion, statt sich auf eine implizite Editor-Konvention zu verlassen.

Die nächste Ebene sind Patches. Stellen Sie diese am Punkt sicher, an dem die Produktionsentscheidung getroffen wird, nicht erst danach, wenn der Nutzer das endgültige Ergebnis an der Oberfläche bemerkt. Je nach Thema können geeignete Verifikationsmaterialien Unreal Insights, eine Gameplay-Debugger-Kategorie, ein Netzwerkdiagnose-Trace, ein AutomationTool-Trace-Log, ein Engine-Asset-Audit, ein erzeugtes Manifest, ein Profiler-Capture oder eine kleine stabile Test-Map sein. Wichtig ist weniger der Debugger als die Erhaltung des Zustands und der verantwortlichen Ebene hinter dem Ergebnis.

Verbinden Sie schließlich Protokolle mit einem Akzeptanzbudget. Ein System kann funktional korrekt sein und dennoch scheitern, weil es zu viel Framezeit, Speicher, Bandbreite, Buildzeit, Paketgröße, genehmigte Wartungsaufmerksamkeit oder Wiederherstellungszeit verbraucht. Verwenden Sie mindestens ein normales Szenario und ein Systemgrenz-Szenario, das der Produktionsskalierung ähnelt. Schließen Sie nicht von einem leeren Titel-Template aus, ohne diese Grenze zu nennen.

Themen-spezifisches Betriebsmodell

Für diesen Leitfaden beginnen Sie mit der Ermittlung der Kamera, der Timecode-Quelle, der Farbtransformation, der aufgezeichneten Take oder des Cluster-Knotens, dem das Shot-Ergebnis gehört. Der erste Prüfpunkt sind die DMX-Libraries, während Fixtures und Patches das Bereitstellungspaket beschreiben, das weiterhin angezeigt werden muss. Lassen Sie nicht zu, dass ein benutzerfreundliches Eigentumsobjekt, eine Editor-Vorschausicht oder eine nachgelagerte Präsentationsschicht zur versehentlichen zweiten autoritativen Quelle wird. Notieren Sie die Eigentumsanforderung zusammen mit der Projektrevision, damit Rückbau- und Neustartverhalten mit der Integration überprüft werden kann.

Die hilfreichsten Belege sind Metadaten der Aufnahme, Timecode-Vergleich, Render-Protokolle, Frame-Captures, Farbkonfiguration sowie Geräte- oder Knotenidentität. Wenden Sie dieses Prüfobjekt auf Patches an, bevor Sie Protokolle optimieren. Eine bestandene Beobachtung muss die Eingangsbedingung, den beobachteten Übergang, das Ausgabebeweisobjekt und die Build-Identität benennen. Wenn ein Tool die konkrete verantwortliche Ebene oder das Timing nicht zeigen kann, setzen Sie statt dessen an der Grenze eine engere Instrumentierung ein, anstatt Korrektheit aus einer visuellen oder auditiven Release-Beobachtung abzuleiten.

Üben Sie Source-Dropout, Retake, Clock Drift, Render-Wiederholung, Node-Verlust, Kamera-Neuzuweisung und Editorial-Handoff. Diese Beispiele sind besonders wichtig, weil der definierende Fehler für diese Seite darin besteht, Geräte zu verbinden, bevor Adressierung, Einheiten, Koordinatenräume, Ratenlimits und sicheres Fallback-Verhalten korrigiert wurden. Stoppen Sie beim ersten Zustand, der der akzeptierenden zuständigen Komponente widerspricht, halten Sie dessen Diagnose-Trace oder Diagnoselog, und beweisen Sie, dass der zweite Lauf oder die Fallback-Revision veraltete Laufzeitressourcen und doppelte Arbeit entfernt. Das Erweitern von Inhalten oder Zielgeräten vor Stabilisierung dieses Rückgabewegs verdeckt die Ursache-Linie der Verantwortung.

Eine produktionsnahe Akzeptanz sollte Frame-Synchronisierung, Renderzeit, ausgelassene Frames, Speicherbedarf, Latenz und Reproduzierbarkeit über Nodes hinweg einbeziehen. Wählen Sie nur die für unreal dmx virtual camera wichtigen Messwerte aus, geben Sie deren Einheiten und Abtastfenster an und bewahren Sie die kontrollierte Produktions-Datenstrecke auf. Die Systementscheidung bleibt, welches externe Steuersignal auf welche Engine-Eigenschaft gemappt wird und wie das Mapping protokolliert und wiederhergestellt wird. Sie gilt erst als abgeschlossen, wenn gewählter Pfad, abgelehnte Alternative, bekannte Einschränkung und Kriterium zur Wiedereröffnung Bestandteil der Übergabe sind.

Entscheidungsrahmen

Die Kernbewertung ist, welches externe Steuersignal auf welche Engine-Eigenschaft abgebildet wird und wie die Zuordnung protokolliert und wiederhergestellt wird. Nutzen Sie die untenstehende Entscheidungsmatrix, um die Wahl im Hinblick auf Teammitglied und Produktionsergebnisse zu sichern statt auf Produktionsfeature-Präferenzen.

Entscheidungsfälle

• Die Verantwortungslage und Lebensdauer sind klar: Halte die kleinste Architektur, die DMX-Bibliotheken sauber freilegt. Erfordere Initialisierung, Mutation, Tear-down und Neustart-Review-Artefakte. Überdenke dies, wenn ein anderer Besitzer beginnt, denselben Zustand zu beschreiben.
• Mehrere Tools scheinen das Produktionsproblem zu lösen: Vergleichen Sie sie über einen repräsentativen Fixture-Betriebspfad mit demselben Spielmaterial, derselben Basislinie, derselben Bereitstellungsumgebung und demselben Abnahmetest. Überdenken Sie, wenn eine Implementierungswahl von verborgenen Projekt- oder Laufzeitzielannahmen abhängt.
• Der erwartete Pfad funktioniert: Erstellen Sie nicht unterstützte, Unterbrechungs-, Neustart- und Skalierungsszenarien. Verlangen Sie einen Aufschlüsselungsindikator sowie saubere Wiederherstellung. Überdenken Sie, wenn der Rückkehrpfad eine nicht automatisierte Reparatur erfordert oder einen veralteten Zustand zurücklässt.
• Version line oder Laufzeitziel-Unterstützung unterscheidet sich: Isolieren Sie den nicht unterstützten Pfad hinter einer deutlich formulierten Vertragsgrenze. Speichern Sie das Datum der technischen Dokumente, das Build-Ergebnis und den Fallback. Überdenken Sie erneut, wenn sich das Fallback auf das für den Spieler sichtbare Verhalten oder die gemessene Last auswirkt.

Legen Sie den autoritativen Besitzer und den diagnostischen Aufzeichnungsweg fest, bevor Sie Implementierungsdetails der Engine ändern. Eine gute Auswahl ist reversibel. Dokumentieren Sie die Entscheidungsgrundlage für die aktuelle Richtung, das verwendete Prüflogobjekt und den Zustand, der sie ungültig macht. Diese Aufzeichnung ist wertvoller als ein langer Funktionssatz, weil sie Personalwechseln und Engine-Updates überdauert.

Implementierungs- und Validierungs-Workflow

1. Baseline einfrieren. Friere den Unreal-Engine-Patch, die Projekt-Revision, Plugins, Zielplattform, Build-Projektkonfiguration und die produktionsnahe Asset-Set-Slice ein. Schreibe die erwarteten Befunde für DMX-Bibliotheken auf, bevor du die Engine-Implementierung anfasst.
2. Zuständigkeit zuweisen. Nennen Sie den Zustand und den Eigentumszeitraum des Zustandsinhabers für Fixtures. Protokollieren Sie, welches Code-Modul, Objekt, Provider, Engine-Asset oder Laufzeitebene diesen Zustand ändern darf und welche Ebenen ihn nur beobachten oder darstellen.
3. Diagnosebeleg sichtbar machen. Bringen Sie Patches durch einen Laufdatensatz, Laufprotokoll, Debugger-Kategorie, Profiler, Manifest oder eine wiederholbare direkte Inspektionsoperation, die für das System geeignet ist, zur Sprache. Verlassen Sie sich nicht darauf, dass ein Shipping-Screenshot das einzige Verifizierungsmaterial ist.
4. Testunterbrechung. Übe den normalen Pfad mit festen Ausgangsbedingungen und wiederhole ihn anschließend mit einem nicht unterstützten Trigger, einer Unterbrechung und einem Neustart bzw. Reconnect. Halte dieselben Freigabestandards für jeden Durchlauf ein.
5. Gemessene Skalierung benchmarken. Quantifizieren Sie Protokolle mit realistischem Projektmaterial und realistischer Hardware. Erfassen Sie Mengen, Zeitfenster, Beispielszenarien und Build-Identität, damit ein späterer Vergleich dieselbe Ausgangsbasis wählt.
6. Publizieren Sie das Auslieferungspaket. Paketieren Sie die Beurteilung als Auslieferungspaket: geänderte Dateien, Voraussetzungen, Reproduktionsbefehl, erforderliche Bereitstellung, bekannte Einschränkung, Eigentümer und das Kriterium, das den Wiederherstellungspfad oder erneute Untersuchungen auslöst.

Dieses Verfahren trennt bewusst Setup, Betriebsdesign, Beobachtung und Abnahme. Wenn ein Test fehlschlägt, kehren Sie zur frühesten Systemgrenze zurück, an der die Evidenz nicht mehr übereinstimmt. Ändern Sie nicht mehrere Parameter und prüfen Sie anschließend nur den Release-Sound-Screenshot; dadurch geht die Ursache-Wirkungskette verloren, die ein anderes Teammitglied benötigt.

Validierungsmatrix

Erforderliche Validierungsausschnitte

• Baseline: Nutzen Sie eine bekannte Projektrevision und minimalen, gemessenen Produktionsdatensatz. Erfassen Sie Besitzer, Übergang, resultierenden Wert und Timing. Bestehen, wenn das Ergebnis ohne verdeckte, vom Operator ausgelöste Aufgaben reproduzierbar ist; andernfalls bewahren Sie den ersten kausalen Trace auf und stoppen Sie die Ausweitung des Implementierungsumfangs.
• Nicht unterstützter Auslöser: Verarbeiten Sie einen fehlenden, fehlerhaften, unbefugten oder nicht verifizierten eingehenden Wert. Erfassen Sie ausdrücklich genannte Ablehnung und unveränderten offiziellen Status. Bestehen, wenn kein Absturz, kein veralteter Zustand und kein stiller Erfolg auftritt; verbessern Sie andernfalls die Qualitätsprüfung auf der verantwortlichen Ebene.
• Interruption: Führen Sie bei Bedarf Bewegungsablauf, Abbruch, Trennung, Rückbau oder Build-Abbruch durch. Erfassen Sie den Rückbau- und Reparaturpfad. Bestehen, wenn das Produktionssystem in einen bekannten Zustand zurückkehrt, ohne manuell ausgelöste Reparatur; andernfalls fügen Sie einen Abbruch-, Timeout- oder transaktionalen Wiederherstellungsweg hinzu.
• Scale: Wähle messbare Akteure, importierte Assets, Nutzer, Frames, Jobs oder Geräte. Erfasse Overhead mit Mengenangaben und aufgenommenen Slice-Bedingungen. Bestehe, wenn die vereinbarte Messmarge Reserve hat; reduziere andernfalls den Arbeitsumfang oder ändere die Architektur vor der Politur.
• Upgrade: Stützen Sie sich auf den Ziel-Engine-Patch, den Projekt-Plugin-Satz oder die Bereitstellungsumgebung-Werkzeugkette. Vergleichen Sie Auslieferungen davor und danach. Bestehen, wenn Verhalten und Ressourcenobergrenze innerhalb der Grenzen bleiben; andernfalls setzen Sie das vorherige Änderungsset zurück und dokumentieren die Inkompatibilität.

Für Unreal DMX Virtual Camera können wertvolle Zahlen Millisekunden pro Frame, Megabytes, replizierte Bytes, Kochzeit in Minuten, Paketgröße, gleichzeitige Runtime-Objekte, aktive Voices, Shader-Varianten, geladene Zellen oder Wiederherstellungssekunden umfassen. Verwende nur Signale, die das tatsächliche System bereitstellt. Wenn ein Parameter nicht profiliert wurde, kennzeichne ihn als unbekannt, anstatt die Seite mit einer Schätzung zu füllen.

Fehlermuster und Wiederherstellung

Ownership Drift

Verantwortungsdrift tritt auf, wenn DMX-Bibliotheken aus mehreren Ebenen ohne dauerhafte Priorität oder Zustandsaktualisierung geändert werden können. Das sichtbare Ergebnis kann zufällig erscheinen, aber die eigentliche Ursache ist meist ein nicht dokumentierter Autoritätsakteur oder ein Ownership-Zyklus. Fügen Sie zustandsbesitzer-spezifisches Verifikationsmaterial hinzu, lehnen Sie unzulässige Schreibzugriffe ab und führen Sie dieselbe Reihe nach travel, reload, reconnect oder teardown erneut aus.

Versions- und Konfigurationsdrift

Editor-Standards, Plugins, Build-Ziele, Runtime-Zieldienstschichten und Codebasis-Projektoptionen ändern sich je nach Engine-Version und Maschine. Speichern Sie den genauen Release-Branch und die Projektkonfiguration neben dem Review-Artefakt. Ein funktionierendes UE 5.8-Beispiel darf nicht als Nachweis für einen älteren Source-Branch oder ein anbieter-spezifisches Produktionsplugin gelten, es sei denn, diese Kombination wurde tatsächlich getestet.

Skalierung hinter einem Happy Path verbergen

Fixtures können mit einem Actor, Engine-Asset, Game User oder Zielgerät funktionieren, während Aufwand und Ausführungsreihenfolge bei realistischer Skalierung scheitern. Erhöhen Sie jeweils nur eine Dimension und protokollieren Sie die erste gemessene Grenzwert- oder Korrektheitsverantwortungslinie. Bewahren Sie den Test-Assetsatz so auf, dass spätere Arbeiten dieselbe Implementierungslücke messen statt eine neu erfundene Benchmark.

Wiederherstellung, die auf manuelle Reparatur angewiesen ist

Behandle Abbruch, veraltete Informationen, verspätete Callbacks und Reversion als Erstklassige Akzeptanzfälle. Für dieses Thema liegt die typische Fehleranfälligkeit im Verbinden von Geräten, bevor Adressierung, Einheiten, Koordinatenräume und sicheres Fallback-Verhalten korrigiert sind. Ein valides Fallback stellt den offiziellen Zustand wieder her, gibt Laufzeitressourcen frei, verhindert doppelte Callbacks oder Berechtigungen und hinterlässt genügend beobachtbaren Nachweis, um zu erklären, was passiert ist. Wenn ein Implementierungsverantwortlicher generierte Zustandswerte löschen oder mehrere Werkzeuge ohne dokumentierte Ursache neu starten muss, ist das Verfahren nicht produktionsreif.

Versions-, Plattform- und Nachweisgrenzen

Diese Seite verwendet die aktive UE 5.8-Dokumentationsoberfläche als ihren aktuellen Referenzpunkt. Epic Games kann den experimentellen Status, Standardwerte, Plugin-Paketierung, APIs, die Unterstützung von Zielplattformen und empfohlene Arbeitsabläufe ändern. Prüfe den Branch-Selektor der technischen Dokumentation und die Release Notes, bevor du Einstellungen in einen anderen Engine-Branch übernimmst. Für umgebungsspezifische Auslieferungsarbeiten ersetzt die Unreal-Richtlinie nicht die offizielle Dokumentation der lizenzierten Bereitstellungsumgebung oder deren Zertifizierungszugang.

Der Artikel liefert eine Methode zur Qualitätsbewertung, nicht die Behauptung, dass SEELE AI oder dieses Repository jedes UE-native Szenario ausgeführt hat. Wenn sich erste Partei-Dokumentation und Workspace-Diagnoseprotokoll unterscheiden, erfasse beide und grenze die Schlussfolgerung auf das getestete Spielprojekt ein. Verstecke den Unterschied nicht, indem du einen Prototyp, Editor-Preview oder eine generierte Illustration als Ergebnis eines verpackten Spiels darstellst.

Checkliste für Teamübergaben

• Fester Unreal Engine Release-Branch, Projektrevision, Plugins, Ziel und Build-Laufzeits-Setup.
• Benannte verantwortliche Ebene für DMX-Bibliotheken und die Grenze zu Fixtures.
• Reproduktionsaufgaben für normale, fehlerhafte, Unterbrechungs-, Fallback- und Skalierungsbeispiele.
• Logs, Traces, Manifeste, Screenshots oder Profiler-Aufzeichnungen mit Build-Identität und Zeitstempeln.
• Benchmarkte Ressourcenobergrenze für Patches und die dahinterliegenden gemessenen Beschränkungen.
• Nicht im Scope liegende Fälle, nicht öffentliche gekoppelte Systeme, Lizenz-Eigentümergrenzen und bekannte Unbekannte.
• Anweisung zum Rücksetzlauf oder zur Quellrevision sowie die Situation, die ihn bzw. sie erforderlich macht.

Ein anderer Programmierer sollte in der Lage sein, die Erkenntnis aus diesem Auslieferungspaket ohne nicht-öffentliche Rechnerpfade oder mündliche Erklärung zu reproduzieren. Wenn er nicht die erste fehlgeschlagene Bedingung benennen kann, muss das überprüfbare Beweispaket verbessert werden, selbst wenn das Produktionsmerkmal anscheinend funktioniert.

SEELE AI-Übergabebereich

SEELE AI kann einem Projektteam helfen, eine Szenenrichtung, Interaktionsschleife, Inhaltsvorgabe, Kameraführung oder einen Testplan zu vergleichen, bevor tiefer in die Unreal-Produktion eingestiegen wird. Dieser vorgelagerte Prototyp kann den beabsichtigten Spieleroutput klären und Mehrdeutigkeiten im In-Project-Setup-Backlog reduzieren. Es handelt sich nicht um eine runtime-native Engine-Integration oder Verifikationsoberfläche.

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 und Operations Guides](/resources/blogs/unreal-engine-worldbuilding-virtual-production-platforms-guides-library) fort, um diese Produktionsentscheidung mit ihren Voraussetzungen, Schwester-Subsystemen, verknüpfter Validierung und Release-Übergaben zu vergleichen. Der Hub ist der kanonische Index für diesen Themenverbund und verlinkt auf jeden fokussierten Guide in der Reihenfolge der Schritte.

• Übersicht über nDisplay für Unreal Engine | Unreal Engine 5.8 Dokumentation | Epic Developer Community — First-Party-Referenz nur für die Antwort, Version oder den Workflow, den sie explizit dokumentiert.
• Movie Render Queue | Unreal Engine 4.27 Dokumentation | Epic Developer Community — Referenz der Erstausrüstung nur für den sichtbaren Effekt, den freigegebenen Branch oder den Workflow, den sie explizit 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.