1. 项目概述当UE4遇上无头Linux服务器在游戏开发、影视渲染或者自动化测试的流水线上我们常常会遇到一个看似矛盾的需求将Unreal Engine 4UE4这样一款以强大图形渲染能力著称的引擎部署到一台没有物理显示器的Linux服务器上。这种服务器通常被称为“无头服务器”Headless Server它们安静地躺在机柜里通过SSH进行管理核心任务就是提供强大的计算能力而不是图形交互。然而UE4的启动和运行尤其是其编辑器模式严重依赖于一个可用的图形显示环境。更棘手的是从某个版本开始UE4在Linux上默认使用Vulkan作为图形后端而Vulkan驱动在无显示设备的环境下往往无法正常初始化直接导致引擎启动失败报出各种与图形API相关的错误。这个项目的核心就是解决这个矛盾。它不是一个简单的“如何安装UE4”的教程而是一套针对特定生产环境无头Linux服务器的工程化解决方案。其目标非常明确让UE4引擎特别是其编辑器能够在一台没有物理显卡和显示器的Linux服务器上稳定运行起来以便执行诸如命令行烘焙光照图、批量导入资源、运行自动化测试脚本或者进行远程渲染等任务。这背后涉及到的关键技术点就是标题中提到的“虚拟显示器”和“-opengl参数”。前者为系统“伪造”出一个可用的显示设备后者则强制UE4使用更“古老”但在此环境下更可靠的OpenGL图形接口从而巧妙地绕过了对Vulkan的硬性依赖。对于谁需要这个方案如果你是负责搭建和维护游戏CI/CD持续集成/持续部署流水线的技术美术或DevOps工程师如果你的团队需要利用云服务器集群进行大规模的UE4项目构建或光照烘焙或者你是一名独立开发者希望用廉价的云服务器来分担本地的计算压力那么这个手把手的指南就是为你准备的。它不仅能帮你把引擎跑起来更重要的是我会分享我在多次部署中踩过的坑和总结出的稳定配置经验让你少走弯路。2. 核心思路与方案选型为什么是虚拟显示器OpenGL在深入命令行之前我们必须先理解为什么常规方法会失败以及我们选择的方案为何有效。这能帮助你在遇到新问题时具备自己分析和解决的能力。2.1 问题根源Vulkan在无头环境下的困境UE4在Linux平台上为了追求更好的性能和更现代的图形特性逐渐将Vulkan作为首选后端。Vulkan是一个低开销、跨平台的图形和计算API但它对硬件和驱动的要求更为严格。在标准的桌面环境下Vulkan通过直接与GPU交互来工作这需要一个“显示服务器”如X11或Wayland和一个有效的显示输出Display作为上下文创建的基石。在无头服务器上问题接踵而至缺少物理显示设备服务器没有插显卡或者有计算卡但没有显示输出接口。系统内核可能根本没有加载drmDirect Rendering Manager模块或者/dev/dri设备节点不存在。Vulkan驱动初始化失败即使安装了Vulkan驱动如mesa-vulkan-drivers驱动在尝试枚举物理设备GPU时很可能因为无法找到任何有效的、支持显示的Vulkan设备而失败。常见的错误信息类似于Failed to find a suitable Vulkan device或Vulkan API version 1.0 is not supported by the selected physical device。UE4的硬性检测UE4启动时会尝试初始化图形渲染器。如果Vulkan初始化失败而你又没有提供备选方案引擎就会直接崩溃退出。那么解决方案的方向就很明确了要么让系统“认为”自己有一个可用的显示设备要么让UE4使用一个不依赖物理显示设备也能初始化的图形API。2.2 方案拆解双管齐下的策略我们的方案正是从这两个方向同时入手虚拟显示器例如Xvfb它的作用是在内存中模拟一个完整的显示服务器X Server和虚拟的显示设备。对于应用程序来说它就像连接了一台真实的显示器可以在上面进行所有的图形绘制操作只不过这些操作的结果不会被输出到物理屏幕而是保存在内存帧缓冲区中。这完美解决了“无显示设备”的根本问题为任何需要图形环境的程序不仅是UE4提供了一个安全的沙箱。-opengl 启动参数这是传递给UE4编辑器可执行文件如UnrealEditor的命令行参数。它的作用是明确告诉UE4引擎“不要尝试自动选择或使用Vulkan后端请直接使用OpenGL进行渲染”。OpenGL是一个更“传统”的图形API其软件实现如Mesa的LLVMpipe或SwiftShader更为成熟在纯CPU渲染的虚拟化环境下兼容性更好更容易在Xvfb创建的虚拟显示环境中成功初始化。为什么这个组合是有效的虚拟显示器Xvfb提供了一个符合规范的图形环境“舞台”。-opengl参数则指定了在这个舞台上使用的“表演语言”。OpenGL作为这个“语言”其软件渲染器与虚拟显示器的兼容性经过了更长时间的考验稳定性高。而Vulkan这个更高效的“新语言”其软件实现和虚拟化环境的适配尚不完善容易“沟通失败”。因此这个组合通过“提供舞台”“使用兼容语言”的方式绕开了Vulkan在无头环境下的初始化难题。备选方案考量 你可能会想到其他方案比如使用mesa的软件Vulkan驱动lavapipe。理论上可行但在我的实测中其稳定性和与UE4的兼容性在复杂项目中仍不及成熟的OpenGL软件渲染路径。另一个方案是使用带有虚拟GPUvGPU的云服务器但这会产生额外的许可费用。对于我们追求稳定、可控且低成本的无头渲染/计算任务Xvfb OpenGL是目前公认的最可靠、最通用的解决方案。3. 基础环境准备与依赖安装工欲善其事必先利其器。在开始配置UE4之前我们需要为Linux服务器搭建好一个能够支持图形渲染的基础环境。这里我以最流行的Ubuntu 20.04/22.04 LTS系统为例其他发行版如CentOS、Rocky Linux的命令包管理器略有不同但核心组件是一致的。3.1 系统更新与基础工具首先通过SSH登录你的无头服务器。确保系统是最新的并安装一些必要的工具。sudo apt update sudo apt upgrade -y sudo apt install -y wget curl git build-essential cmake python3 python3-pip注意build-essential和cmake是编译UE4或其部分工具链所必需的。即使你打算使用预编译的引擎版本安装它们也能避免一些潜在的运行时库问题。3.2 安装图形与虚拟显示环境这是最关键的一步。我们需要安装X Window系统的基础组件、虚拟帧缓冲区以及OpenGL的实现库。# 安装X11服务端、客户端基础库以及虚拟帧缓冲区Xvfb sudo apt install -y xserver-xorg-core xserver-xorg-video-dummy xvfb # 安装Mesa OpenGL库包含软件渲染器LLVMpipe sudo apt install -y mesa-utils libgl1-mesa-glx libgl1-mesa-dri # 可选但推荐安装一些常用的字体避免UE4编辑器因缺少字体而出现界面显示问题 sudo apt install -y fonts-liberation fonts-dejavu-core组件解释xserver-xorg-core: X Window系统的核心服务端。xserver-xorg-video-dummy: 一个虚拟的X11显示驱动它模拟一个显示设备与Xvfb配合工作。xvfb: X Virtual Frame Buffer我们方案的核心它创建一个没有物理输出的虚拟显示服务器。mesa-utils: 包含glxinfo等诊断工具。libgl1-mesa-glxlibgl1-mesa-dri: Mesa提供的OpenGL库和直接渲染基础设施是OpenGL软件渲染的基石。安装完成后你可以运行glxinfo | grep “OpenGL”来测试OpenGL是否可用但这通常需要在一个真实的X会话中在无头环境下直接运行会报错我们先不急。3.3 验证虚拟显示器Xvfb的安装我们可以先独立测试Xvfb是否能正常工作。# 在后台启动一个Xvfb实例显示编号为:99屏幕尺寸为1920x1080色深24位 Xvfb :99 -screen 0 1920x1080x24 # 记录下进程ID例如 12345 XVFB_PID$! # 设置环境变量让后续命令使用这个虚拟显示器 export DISPLAY:99.0 # 尝试运行一个需要X11的小程序例如xeyes需要先安装 x11-apps sudo apt install -y x11-apps xeyes # 如果xeyes的进程能启动可以用ps aux | grep xeyes查看说明Xvfb工作正常。 # 由于没有物理输出你看不到眼睛窗口但进程存在即成功。 # 测试完成后清理 kill $XVFB_PID如果上述步骤没有报错说明你的虚拟显示环境已经就绪。在实际运行UE4时我们将以服务或脚本的形式更优雅地管理Xvfb。4. 获取与配置Unreal Engine 4有了基础环境接下来就是主角UE4了。你有两个主要选择从Epic Games Launcher下载预编译版本或者从GitHub克隆源码自行编译。对于无头服务器我强烈推荐使用预编译版本因为从源码编译UE4是一个极其耗时数小时到数十小时且对系统资源要求很高的过程在服务器上操作并不经济。4.1 获取预编译的UE4版本在本地机器有图形界面的Windows/Mac/Linux上通过Epic Games Launcher安装你所需的UE4版本例如4.27.2。安装完成后在Launcher的“库”中找到该引擎版本点击右侧的“...”菜单选择“复制路径”。这个路径就是引擎的根目录。我们需要将其整个打包上传到服务器。引擎目录很大约30-80GB建议使用rsync进行增量同步或者打包成多个分卷。# 在本地机器示例为Linux/macOS终端操作 ENGINE_PATH/path/to/your/UnrealEngine/4.27 # 替换为你的实际路径 tar -czf ue4-4.27.tar.gz -C $(dirname $ENGINE_PATH) $(basename $ENGINE_PATH) # 然后使用scp或rsync上传到服务器 scp ue4-4.27.tar.gz useryour_server_ip:/tmp/在服务器上解压并放置到合适位置例如/opt/UnrealEngine/4.27。sudo mkdir -p /opt/UnrealEngine sudo tar -xzf /tmp/ue4-4.27.tar.gz -C /opt/UnrealEngine/ # 确保你的用户有读取和执行权限 sudo chown -R $USER:$USER /opt/UnrealEngine/4.274.2 安装必要的运行时库UE4的二进制文件依赖于一些特定的系统库。即使你安装了基础的Mesa也可能缺少一些。通常需要补充安装以下库sudo apt install -y libxcb-xinerama0 libxcb-icccm4 libxcb-image0 libxcb-keysyms1 libxcb-randr0 libxcb-render-util0 libxcb-shape0 libxcb-sync1 libxcb-xfixes0 libxcb-xkb1 libxkbcommon-x11-0如果启动时仍报告缺少.so文件可以根据错误信息使用apt-file search命令来查找对应的包。4.3 准备一个测试项目为了验证配置是否成功你可以在服务器上创建一个空项目或者上传一个已有的简单项目。这里我们在服务器上创建一个空项目。首先进入引擎的Engine/Binaries/Linux目录找到UnrealEditor可执行文件。我们通过命令行工具来生成项目。cd /opt/UnrealEngine/4.27/Engine/Binaries/Linux # 使用 -project 参数指定一个新项目路径-game 表示以游戏模式运行这里用来生成项目 ./UnrealEditor -project/home/$USER/MyTestProject/MyTest.uproject -game -stdout -unattended这条命令可能会因为缺少显示环境而失败这很正常。我们真正的测试将在配置好虚拟显示器后进行。-stdout和-unattended参数对于无头运行非常重要前者确保所有日志输出到控制台后者使引擎以非交互模式运行避免等待用户输入。5. 核心配置整合虚拟显示器与UE4启动现在我们将所有部分组合起来创建一个一键启动脚本。这个脚本将负责启动Xvfb、设置环境变量并在该环境中运行UE4编辑器。5.1 创建启动脚本在你的用户目录下例如/home/$USER/创建一个名为run_ue4_headless.sh的脚本。#!/bin/bash # run_ue4_headless.sh # 用于在无头服务器上启动UE4编辑器 # 1. 定义变量 DISPLAY_NUM:99 SCREEN_RESOLUTION1920x1080x24 UE4_EDITOR_PATH/opt/UnrealEngine/4.27/Engine/Binaries/Linux/UnrealEditor UPROJECT_PATH/home/$USER/MyTestProject/MyTest.uproject LOG_FILE/tmp/ue4_editor_$(date %Y%m%d_%H%M%S).log # 2. 检查Xvfb是否已在运行 if ps aux | grep -v grep | grep -q Xvfb $DISPLAY_NUM; then echo [INFO] Xvfb is already running on $DISPLAY_NUM. else echo [INFO] Starting Xvfb on $DISPLAY_NUM with resolution $SCREEN_RESOLUTION... Xvfb $DISPLAY_NUM -screen 0 $SCREEN_RESOLUTION -ac -nolisten tcp XVFB_PID$! sleep 3 # 给Xvfb一点启动时间 if kill -0 $XVFB_PID 2/dev/null; then echo [INFO] Xvfb started successfully (PID: $XVFB_PID). else echo [ERROR] Failed to start Xvfb. Exiting. exit 1 fi fi # 3. 设置环境变量 export DISPLAY$DISPLAY_NUM.0 # 可选强制使用软件OpenGL确保不会尝试使用不存在的硬件加速 export LIBGL_ALWAYS_SOFTWARE1 # 4. 启动UE4编辑器 echo [INFO] Launching UE4 Editor for project: $UPROJECT_PATH echo [INFO] Logs will be saved to: $LOG_FILE # 核心启动命令 $UE4_EDITOR_PATH $UPROJECT_PATH \ -opengl \ # 强制使用OpenGL渲染器 -nosplash \ # 不显示启动画面 -unattended \ # 无人值守模式不弹出模态对话框 -stdout \ # 将日志输出到标准输出 -FullStdOutLogOutput \ # 更完整的日志输出 -log \ # 启用日志记录 -RenderOffScreen \ # 离屏渲染模式适合无头环境 -ForceRes \ # 强制使用指定分辨率如果需要 -ResX1920 -ResY1080 \ 21 | tee $LOG_FILE # 同时输出到控制台和日志文件 UE4_PID$! echo [INFO] UE4 Editor started (PID: $UE4_PID). # 5. 等待UE4进程结束 wait $UE4_PID UE4_EXIT_CODE$? echo [INFO] UE4 Editor process exited with code: $UE4_EXIT_CODE # 6. 清理如果Xvfb是由本脚本启动的则关闭它 if [ -n $XVFB_PID ] kill -0 $XVFB_PID 2/dev/null; then echo [INFO] Stopping Xvfb (PID: $XVFB_PID)... kill $XVFB_PID fi exit $UE4_EXIT_CODE给脚本添加执行权限chmod x ~/run_ue4_headless.sh5.2 脚本关键参数详解-opengl:灵魂参数。明确指示UE4使用OpenGL渲染后端。这是绕过Vulkan依赖的关键。-unattended: 无人值守模式。在此模式下引擎不会弹出任何需要用户点击的对话框如“首次运行设置”、“崩溃报告”这对于自动化脚本至关重要。-stdout-FullStdOutLogOutput: 将所有日志信息重定向到标准输出控制台。在无头环境中这是你查看引擎状态和调试问题的唯一窗口。-RenderOffScreen: 建议启用。它告诉引擎进行离屏渲染与虚拟显示器的配合更好。-ResX-ResY: 指定渲染分辨率。应与Xvfb启动时的屏幕分辨率一致避免不必要的缩放开销。-nosplash: 禁用启动闪屏减少不必要的图形初始化步骤。实操心得-unattended参数非常重要。我曾经遇到过因为引擎弹出一个“发送错误报告”的对话框导致整个自动化脚本挂起数小时的情况。加上这个参数后引擎在遇到非致命错误时会直接跳过对话框继续运行或退出。6. 运行测试与验证现在运行我们的脚本进行第一次实战测试。cd ~ ./run_ue4_headless.sh如果一切顺利你将在终端看到大量的UE4启动日志滚动。耐心等待几分钟直到看到类似以下信息表明编辑器已成功加载项目并进入空闲状态LogInit: Display: Running engine for game: MyTest LogLoad: Game class is ‘MyTestGameMode’ LogWorld: Bringing World /Game/Untitled.Untitled up for play (max tick rate 60) at 2023.10.27-12.00.00 LogEngine: Initializing Engine... ... LogTemp: Warning: Warning message here... ... LogInit: Display: Engine is initialized and ready.此时UE4编辑器已经在虚拟显示器中运行起来了。虽然你看不到界面但它已经可以接受命令了。6.1 执行一个简单命令验证我们可以通过UE4的Exec命令功能来验证编辑器是否真的在运行并响应。打开另一个SSH终端使用ps aux找到UnrealEditor的进程ID然后向它发送一个命令。更优雅的方式是在启动脚本中让UE4自动执行一些任务。例如修改启动命令让它执行一个控制台命令后退出# 在启动命令后添加 -ExecCmds 参数 $UE4_EDITOR_PATH $UPROJECT_PATH \ -opengl \ -nosplash \ -unattended \ -stdout \ -FullStdOutLogOutput \ -log \ -RenderOffScreen \ -ExecCmdsrhi.PrintMemoryStats; Quit \ # 打印图形内存状态后退出 21 | tee $LOG_FILE如果能在日志中看到rhi.PrintMemoryStats命令的输出关于OpenGL内存的使用情况并且进程正常退出返回码为0那就铁证如山——你的UE4已经在无头Linux服务器上成功运行了6.2 验证图形API在日志中搜索“OpenGL”或“RHI”你通常会看到类似这样的行确认了OpenGL正在被使用LogRHI: Using OpenGL 4.6 (Core Profile)... LogRHI: OpenGL Device: llvmpipe (LLVM 15.0.7, 256 bits) LogRHI: OpenGL Vendor: Mesa/X.org注意设备名是llvmpipe这是Mesa的软件OpenGL实现它完全运行在CPU上。这正是我们想要的效果——在无GPU的服务器上实现图形兼容。7. 常见问题排查与性能调优即使按照步骤操作你也可能会遇到一些问题。这里我整理了在多次部署中遇到的一些典型“坑”及其解决方案。7.1 启动崩溃或黑屏无日志输出症状运行脚本后进程立刻退出LOG_FILE里没有内容或只有开头几行。排查检查Xvfb确保Xvfb成功启动。可以手动运行Xvfb :99 -screen 0 1920x1080x24 然后用export DISPLAY:99.0和xeyes 测试。检查权限确保你的用户对UE4引擎目录和项目目录有读取和执行权限。检查库依赖运行ldd $UE4_EDITOR_PATH | grep “not found”查看是否有缺失的动态链接库。根据缺失的库名用apt-file search查找并安装对应包。直接运行测试在脚本中注释掉启动UE4的命令先手动设置DISPLAY然后直接运行$UE4_EDITOR_PATH -version。看是否有更详细的错误输出到终端。7.2 日志中出现“Failed to create vertex shader”或“OpenGL context creation failed”症状引擎启动一段时间后崩溃日志中有OpenGL相关的着色器或上下文创建失败信息。解决方案更新Mesa系统自带的Mesa版本可能太旧。考虑添加kisak-mesaPPA针对Ubuntu来安装更新的Mesa驱动。sudo add-apt-repository ppa:kisak/kisak-mesa sudo apt update sudo apt upgrade增加虚拟显存软件渲染器使用系统内存作为显存。如果项目复杂可能需要增加Xvfb的虚拟显存深度。将启动参数中的24色深改为32这有时能提供更大的颜色缓冲区。SCREEN_RESOLUTION“1920x1080x32”尝试SwiftShader如果Mesa的LLVMpipe问题依旧可以尝试Google的SwiftShader一个高效的软件渲染器。但这需要从源码编译并配置环境变量指向它步骤更复杂可作为备选方案。7.3 性能低下CPU占用率100%症状执行光照烘焙或渲染时速度极慢top命令显示一个CPU核心被占满。分析与调优这是预期行为软件OpenGL渲染LLVMpipe是单线程的并且完全依赖CPU。一个复杂的渲染操作占满一个核心是正常的。多任务并行如果你的服务器有多核不要只运行一个UE4实例。你可以编写脚本同时启动多个Xvfb实例如:99,:100等并在不同的DISPLAY下运行多个UE4进程处理不同的任务或地图从而充分利用多核CPU。例如用于并行烘焙多个光照贴图。降低分辨率在Xvfb和-ResX/ResY参数中使用更低的分辨率如1280x720可以显著减少软件渲染的像素填充负担提升操作响应速度。优化项目设置在无头服务器上运行的项目应关闭所有不必要的视觉效果和后处理。在项目设置中将默认的图形质量设置为“Low”或自定义一个极简的配置。7.4 如何运行自动化命令如构建光照、打包成功启动只是第一步我们的目标是让UE4自动执行任务。这需要通过-ExecCmds参数或外部自动化工具如Python的unreal模块来实现。示例在无头服务器上烘焙项目光照$UE4_EDITOR_PATH “$UPROJECT_PATH” \ -opengl \ -unattended \ -stdout \ -FullStdOutLogOutput \ -ExecCmds“BuildAll” \ # 构建所有内容包括光照 -runBuildCookRun \ # 运行构建、烹饪、运行流程 -targetplatformLinux \ # 目标平台 -buildscook \ -skipcook \ -skipstage \ -skippackage \ -CrashForUAT \ 21 | tee “$LOG_FILE”示例运行一个自定义的Python脚本首先在项目目录下创建Scripts/MyAutomation.py然后$UE4_EDITOR_PATH “$UPROJECT_PATH” \ -opengl \ -unattended \ -stdout \ -ExecutePythonScript“Scripts/MyAutomation.py” \ 21 | tee “$LOG_FILE”避坑技巧在-ExecCmds中多个命令用分号;分隔。如果命令本身包含空格或特殊字符需要用引号包裹。对于复杂的自动化强烈建议使用Python脚本它更强大、更灵活也更容易调试。你可以先在本地有图形界面的编辑器里调试好脚本再放到服务器上运行。8. 进阶部署将无头UE4作为系统服务对于生产环境我们不应该每次手动运行脚本。更好的方法是将它配置为一个系统服务systemd service实现开机自启、崩溃重启和集中日志管理。8.1 创建Systemd服务单元文件创建一个文件/etc/systemd/system/ue4-headless.service[Unit] DescriptionUnreal Engine 4 Headless Editor Service Afternetwork.target [Service] Typeforking Useryour_username # 替换为你的用户名 Groupyour_username Environment“DISPLAY:99.0” Environment“LIBGL_ALWAYS_SOFTWARE1” WorkingDirectory/home/your_username ExecStartPre/usr/bin/Xvfb :99 -screen 0 1920x1080x24 -ac -nolisten tcp ExecStart/bin/bash -c ‘sleep 3 /opt/UnrealEngine/4.27/Engine/Binaries/Linux/UnrealEditor /home/your_username/MyTestProject/MyTest.uproject -opengl -nosplash -unattended -stdout -FullStdOutLogOutput -log -RenderOffScreen’ Restarton-failure RestartSec10s StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target关键点说明Typeforking: 因为我们要先启动Xvfb一个后台进程再启动UE4。ExecStartPre: 在启动主服务前先启动Xvfb。ExecStart中的sleep 3: 给Xvfb几秒钟时间完成初始化。Restarton-failure: 如果UE4进程异常退出系统会自动在10秒后重启它。StandardOutputjournal: 将所有日志输出到systemd日志可以用journalctl -u ue4-headless.service查看。8.2 启用并管理服务# 重新加载systemd配置 sudo systemctl daemon-reload # 启动服务 sudo systemctl start ue4-headless.service # 查看服务状态和日志 sudo systemctl status ue4-headless.service sudo journalctl -u ue4-headless.service -f # 实时跟踪日志 # 设置开机自启 sudo systemctl enable ue4-headless.service通过这种方式你的无头UE4编辑器就变成了一个可靠的后台服务可以7x24小时运行随时等待执行自动化任务。8.3 性能监控与资源限制在服务文件中你还可以添加资源限制防止UE4进程占用过多资源影响服务器其他服务。[Service] ... # 限制CPU使用率为200%即最多使用两个核心 CPUQuota200% # 限制内存使用为8GB MemoryMax8G # 限制虚拟内存为16GB MemorySwapMax16G根据你的服务器配置和任务需求合理设置这些参数可以确保系统的整体稳定性。从最初的Vulkan依赖报错到最终建立起一个稳定运行在无头Linux服务器上的UE4自动化服务这个过程涉及了系统配置、图形原理和工程实践多个层面。核心的虚拟显示器 -opengl方案之所以有效是因为它精准地解决了“无显示硬件”与“现代图形API依赖”之间的矛盾用经过充分测试的软件兼容层替代了不稳定的硬件抽象层。在实际部署中最大的挑战往往不是方案本身而是对细节的把握库依赖是否完整、环境变量是否正确传递、启动参数是否适配你的具体任务。我建议你在自己的服务器上操作时养成查看完整日志的习惯任何错误信息都是下一步行动的线索。这个方案不仅适用于UE4其思路也可以迁移到其他需要在无头环境下运行图形化应用的场景比如基于Unity的批量处理、或者一些传统的图形渲染农场。当你成功在命令行中看到UE4的日志开始滚动时那种将强大的图形工具纳入自动化流程的掌控感就是对我们这些后台工程师最好的回报。