Wie am Ende des letzten Artikels bereits angekündigt, werden wir uns in diesem Artikel anschauen, wie man die Unreal Engine unter Linux verwendet. Es freut mich auch sehr 😊, dass ich aus verschiedenen Richtungen gehört habe, dass es Menschen gibt, die sich auf diesen Artikel freuen. Wir fangen dabei mit der vorkompilierten Variante, also der Binärversion, an und arbeiten uns dann Schritt für Schritt weiter voran, um am Ende die Unreal Engine selbst zu kompilieren. Dabei betrachten wir natürlich auch die Einschränkungen unter Linux und auch mögliche Workarounds bei Kompatiblitätsproblemen.

Bevor es wirklich losgeht, hier wie gewohnt die Übersicht über alle bislang erschienen Artikel dieser Serie:

1. Linux? Was zum Pinguin!?
2. Grundlegende Installation der Linux Distribution
3. Installation von nativer Linux-Software
4. Installation von Windows-Software unter Linux
5. Gaming unter Linux
6. Die Unreal Engine unter Linux

Einschränkungen unter Linux

Vorab eine Übersicht der harten Einschränkungen beim Einsatz der Unreal Engine unter Linux:

• Im Gegensatz zu Windows ist die Möglichkeit zur Cross-Compilation unter Linux eingeschränkt. Während man unter Windows für annähernd jede unterstützte Plattform, außer MacOS und iOS, kompilieren kann, ist es unter Linux nur für Linux selbst und Android möglich. Zumindest haben das meine bisherigen Recherchen ergeben, aber ich lasse mich gerne eines Besseren belehren.

• Es steht einzig Vulkan als RHI (Rendering Hardware Interface) zur Verfügung, genauer gesagt Vulkan Desktop (SM5), Vulkan Desktop (SM6) und Vulkan Mobile (ES3.1).

• Es kann zu Inkompatibilitäten bei 3rd-Party-Plugins kommen.

Sollte einer der Punkte zu Problemen bei euch führen, so könnt ihr die Unreal Engine leider nicht unter Linux einsetzen.

Vorkompilierte Version

Das ist wohl der Startpunkt für die meisten Hobby-Entwickler. Man könnte es auch vermarkten als: Herunterladen, “Installieren” und Loslegen. Epic Games ist mittlerweile so freundlich und stellt seit der Veröffentlichung von Unreal Engine 5 eine offizielle vorkompilierte Version bereit. Benötigt wird dafür natürlich ein kostenloser Epic Entwickler Account, aber den benötigt man ja generell, wenn man mit der Unreal Engine arbeiten möchte. Nachdem man eingeloggt ist, bekommt man eine Auflistung aller zum Download verfügbaren Versionen angezeigt und kann diese herunterladen. Die Größe des Zip-Archivs schwankt je nach Version zwischen ~20 GB - ~30 GB.

Nach dem Download kann man das Zip-Archiv an jeder beliebigen Stelle entpacken. Ich nutze dafür meinen Ordner ~/dev, in welchem ich für jede installierte UE-Version einen entsprechenden Unterordner habe, also bspw. ~/dev/UE-5.7.1 für Unreal Engine 5.7.1. Gestartet wird die Unreal Engine dann durch den Unreal Editor, dessen ausführbare Datei unterhalb von Engine/Binaries/Linux/UnrealEditor “versteckt” ist. Anschließend öffnet sich die, auch von Windows, gewohnte Oberfläche zum Anlegen neuer Projekte. Ab hier sollte eigentlich alles wie unter Windows funktionieren.

Um auch direkten Zugriff auf die Assets von Fab.com zu haben, ist die Installation des passendes Plugins notwendig. Herunterladen lässt es sich auf der gleichen Seite wie Unreal. Den Inhalt des Zip-Archivs kann man nun einfach im Hauptordner der Unreal Engine entpacken. Nun sollte das Plugin in jedem Unreal-Projekt automatisch aktiv sein, sodass man unter Window -> Fab den zugehörigen Browser starten kann.

Die Version 5.7 beinhaltet ein Upgrade auf SDL-3, welches aktuell noch ein paar Kompatibilitätsprobleme mit Wayland hat, die wir uns dann unter Probleme mit SDL3 noch genauer anschauen. Aber auch der Rest des Troubleshooting-Abschnitts ist hoffentlich interessant.

Unreal selbst kompilieren

Es kann verschiedene Gründe geben, warum einem die von Epic vorkompilierte Version der Unreal Engine nicht ausreicht. Seien es nachgerüstete Funktionalitäten oder Performanceoptimierungen, es kann wirklich viele Gründe geben, die Unreal Engine auf den eigenen benötigten Funktionsumfang anzupassen. Um dies unter Linux zu tun, gibt es auch eine offizielle Anleitung, die ich als Basis für den Rest des Abschnitts benutzt habe.

Generell sei gesagt, dass dieser Weg der UE-Nutzung höhere Anforderungen an die Hardware hat als der Weg mit der vorkompilierten Version. Mit weniger als 32 GB RAM sollte man es erst gar nicht versuchen. Den Grund dafür sehe ich in erster Linie darin, dass man für eine höhere Entwicklungsgeschwindigkeit nicht immer mit der besten Optimierung kompilieren will bzw., wenn es um das Thema Debugging geht, auch nicht unbedingt kann.

Interessanterweise findet man in der Dokumentation auch die PC-Spezifikationen eines typischen Systems bei Epic für die Entwicklung mit der Unreal Engine 5 unter Linux:

• Betriebssystem: Ubuntu 22.04
• Prozessor: AMD Ryzen Threadripper Pro 3975WX Processor - 128MB Cache, 3.5 GHz base / 4.2 GHz turbo, 32 Cores / 64 Threads, 280 W TDP
• RAM: 128GB DDR4-3200
• GPU: Nvidia RTX 3080 - 10GB
• Speicher:
  • Betriebssystem: 1 TB M.2 NVMe3 x4 PCI-e SSD
  • Daten: 4 TB Raid Array - 2 x 2TB NVMe3 x4 PCI-e SSD in Raid 0

Meine eigene Hardware kann zwar nicht mit dem Prozessor oder der RAM-Größe konkurrieren, aber mit mindestens 32 GB RAM und einem halbwegs leistungsstarken Prozessor sollte es keine größeren Probleme geben. Und man benötigt natürlich ausreichend Speicherplatz. In meinen Tests für diesen Artikel war mein Ordner am Ende gut 225 GB groß.

Der erste Schritt ist es, das Git-Repository von Unreal zu klonen. Falls ihr noch keinen Zugriff auf das Git-Repository haben solltet, benötigt ihr einen kostenlosen Epic-Account und müsst diesen anschließend mit eurem GitHub-Account verknüpfen:

1. Erstellt einen GitHub-Accounts, sofern ihr noch keinen habt.
2. Loggt euch auf der Unreal Engine-Website ein und navigiert auf die Konto-Einstellungen
3. Geht auf den Reiter Verknüpfte Konten und verknüpft euren GitHub-Account mit eurem Epic-Account.
4. Nachdem ihr die Accounts miteinander verknüpft habt und anschließend auch EpicGames auf GitHub autorisiert habt (die Aufforderung sollte automatisch kommen), bekommt ihr zeitnah eine E-Mail von GitHub, um euch in die Organisation @EpicGames einzuladen.
5. Wenn ihr dieser Einladung folgt, bekommt ihr Zugriff auf das Git-Repository

Sollte euch diese Anleitung zu kurz sein, könnt ihr auch die offizielle Anleitung dazu anschauen.

Nach dem erfolgreichen Klonen des Repositories ist der nächste Schritt, das Skript Setup.sh auszuführen, welches sich direkt auf oberster Ebene des Repositories befindet. In diesem aktuell 90 Zeilen langen Skript geht es in erster Linie darum, alle Abhängigkeiten herunterzuladen und passend abzulegen und das Skript für die Abhängigkeiten als Git-Hooks für post-checkout und post-merge zu hinterlegen. Im Endeffekt wird dazu die zum OS passende ausführbare Datei GitDependencies (bspw. Engine/Binaries/DotNET/GitDependencies/linux-x64/GitDependencies) aufgerufen, die dann nochmals gut 29GB an Daten herunterlädt. Damit dieser Download nicht bei jedem Checkout oder Merge komplett bei 0 anfangen muss, wird .git/ue-gitdeps als Cache genutzt. Es kann also beim ersten Ausführen etwas dauern.

Im nächsten Schritt geht es darum, die Toolchain passend aufzusetzen. Auch dafür hat Epic freundlicherweise ein entsprechendes Skript erstellt, sodass wir nur noch in den Unterordner Engine/Build/BatchFiles/Linux gehen müssen, um dort das Skript SetupToolchain.sh auszuführen. Dieses Skript hat aktuell in der Linux-Version 98 Zeilen und lädt ein Archiv, welches eine Linux-Version von Clang enthält, aus dem CDN von Epic herunter und entpackt es unterhalb von Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64. (Interessanterweise wird es unterhalb von .git/ue4-sdks gecached.)

Bevor wir nun das Kompilieren starten können, fehlt noch die Generierung der Projektdateien bzw. der Solution, wie es bei Visual Studio heißen würde. Dafür gehen wir in den Unterordner Engine/Build/BatchFiles/Linux und führen GenerateProjectFiles.sh aus. Als Übergabeparameter können wir dann die gewünschte Entwicklungsumgebung mitgeben, sodass dafür passende Projektdateien erzeugt werden. Herauszufinden, welche Übergabeparameter nun wirklich möglich sind, hat mich etwas Detektivarbeit gekostet, aber letztendlich bin ich in der Datei Engine/Source/Programs/UnrealBuildTool/Modes/GenerateProjectFilesMode.cs dann auf die entsprechenden Informationen gestoßen. Unterstützt werden dabei:

• Make (-Makefile)
• CMake (-CMakefile)
• QMake (-QMakefile)
• KDevelop (-KDevelopfile)
• CodeLite (-CodeLitefiles)
• VisualStudio (-VisualStudio)
• VisualStudio2022 (-2022)
• VisualStudioWorkspace (-VSWorkspace)
• XCode (-XCodeProjectFiles)
• Eddie (-EddieProjectFiles)
• VisualStudioCode (-VSCode)
• CLion (-CLion)
• Rider (-Rider)
• AndroidStudio (-AndroidStudio)

Nun können wir das erstellte Projekt in der Entwicklungsumgebung unserer Wahl öffnen und darin dann den Task “Launch UnrealEditor (<FLAG>)” starten, wobei <FLAG> dem gewünschten Optimierungsgrad entspricht.

Sobald der Task erfolgreich abgeschlossen wurde, was, abhängig vom gewählten Optimierungsgrad und der eigenen CPU, etwas dauern kann, gibt es nun unterhalb von Engine/Binaries/Linux/ eine ausführbare Datei namens UnrealEditor-Linux-<FLAG>, mit der man jetzt die selbstkompilierte Version der UnrealEngine starten kann.

Troubleshooting

Hohe CPU-Last im Idle

Manchmal kann es vorkommen, dass ein gestarteter Unreal Editor überraschend viel Last auf dem PC erzeugt, obwohl man gerade gar keine aufwendigen Dinge im Unreal Editor macht. Falls ihr mal ein solches Gefühl haben solltet, dann könntet ihr euch mal anschauen, welcher Prozess die Last erzeugt. Eine gute Möglichkeit dafür ist htop, was wir uns im letzten Artikel schon mal kurz angeschaut haben. Solltet ihr sehen, dass es da einen Prozess namens EpicWebHelper gibt, der viel Last erzeugt, könnt ihr diesen ruhigen Gewissens beenden.

Es passiert nicht bei jedem Start, aber hin und wieder läuft dieser Prozess Amok, und bislang habe ich noch keine negativen Auswirkungen festgestellt, wenn ich ihn beendet habe.

Probleme mit SDL3 (UE 5.7.x)

Wie eingangs schon geschrieben, gibt es durch das Upgrade auf SDL-3 aktuell ein paar Kompatibilitätsprobleme mit Wayland. Das ist besonders unpraktisch, da Wayland immer mehr Verbreitung findet und für die meisten Distributionen mittlerweile der Standard ist. Aber wir wären nicht unter Linux, wenn es nicht auch findige Menschen gäbe, die passende Workarounds entwickelt hätten. Dabei gehöre ich nicht zu diesen findigen Menschen, sondern bin eher ein Nutznießer, da ich glücklicherweise den passenden Thread gefunden habe.

Der wichtigste Fix ist es, den Unreal Editor mit der Umgebungsvariable SDL_VIDEODRIVER=x11 zu starten, um so SDL anzuweisen, das Fenster mit X11 anstatt Wayland zu starten. Lässt man dies weg und der Unreal Editor startet mit Wayland, werden aktuell leider alle Pop-Ups, also bspw. auch alle (Unter-)Menüs, mittig auf dem Bildschirm platziert.

Das zweite, auch sehr nervige, Problem ist, dass jeder Tooltip als eigenes Fenster gezählt wird. Das hat zur Folge, dass man, wenn auf etwas klicken möchte, was via Mouseover einen Tooltip erzeugt, zweimal klicken muss, da jeder Tooltip mit seinem Erscheinen den Fokus klaut. Um dieses Problem anzugehen, gibt es aktuell die folgenden Workarounds:

1. Deaktivieren der Tooltips (radikal): In der Datei Config\DefaultEngine.ini die folgenden Zeilen hinzufügen:

   [SystemSettings]
   Slate.EnableTooltips=False
   

2. Verzögern der Tooltips (nicht ganz so radikal): Für ein Delay von 2s könnt ihr in der Datei Config\DefaultEngine.ini die folgenden Zeilen hinzufügen:

   [SystemSettings]
   Slate.TooltipSummonDelay=2.0
   

3. Erstellen einer eigenen “Fensterregel”: Dank der hohen Anpassbarkeit der Linux-Desktopumgebungen kann man das Problem in der Regel auch umgehen, ohne das Verhalten der Unreal-Tooltips zu verändern. Denn viele Desktopumgebungen bieten die Möglichkeit, eigene Regeln für das Verhalten von Fenstern zu definieren. Damit ist es möglich, die Umgebung so zu konfigurieren, dass die Tooltips nicht mehr den Fokus vom Unreal Editor stehlen. Das folgende Beispiel ist für Plasma / KDE, aber auch viele alternative Desktopumgebungen bieten ähnliche Funktionalität. Dafür erstellt ihr mit Systemeinstellungen -> Fensterverwaltung -> Fensterregeln -> + Neu hinzufügen ... eine neue Fensterregel mit folgenden Parametern:

   • Fensterklasse (Programm): UnrealEditor
   • Fenstertypen: Alle, außer “Normales Fenster”
   • Verhindern unerwünschter Aktivierung: Erzwingen / Extrem
   • Fokusschutz: Erzwingen / Deaktiviert
   • Aktivierung zulassen: Erzwingen / Nein

   Für ein besseres Verständnis habe ich auch noch einen Screenshot von meiner Regel gemacht:

   

StarterContent wieder verfügbar machen

Mit der Version 5.7 hat sich Epic scheinbar dazu entschieden, den StarterContent nicht mehr mit auszuliefern. Das sollte in der Regel eigentlich kein großes Problem sein, da große Teile des StarterContents mittlerweile auch in die Jahre gekommen sind, aber gerade, wenn man mal eben schnell was testen möchte, finde ich ihn doch sehr praktisch. Um auch in 5.7 die Möglichkeit zu haben, den StarterContent zu nutzen, benötigen wir zuerst eine ältere Version der Unreal Engine, bspw. 5.6.1. Aus der älteren Unreal-Version kopieren wir dann den Ordner Samples in den Hauptordner der 5.7 und anschließend kopieren wir die Datei FeaturePacks/StarterContent.upack in den Ordner FeaturePacks der 5.7. Nach einem Neustart des Unreal Editors können wir nun, wie gewohnt, über den Content-Browser den StarterContent hinzufügen: +Add (oder Rechtsklick im Content-Browser) -> Add Feature oder Content Pack... -> Content -> Starter Content -> Add to Project.

Fazit & Ausblick

Ich hoffe, euch hat auch dieser Artikel gefallen. Aktuell bin ich mir noch nicht sicher, welches Thema ich im nächsten Artikel dieser Reihe näher beleuchten werde, aber vielleicht zeige ich euch eine (meiner Meinung nach) sehr angenehme Backup-Lösung.