UE4 与 UE5：技术差异深度解析

UE4 与 UE5：技术差异深度解析

虚幻引擎 4（UE4）与虚幻引擎 5（UE5）代表了游戏引擎发展的两个时代。本文从技术角度全面对比两者的核心差异，帮助开发者做出合适的技术选择。

---

一、架构演进：继承与革新

基础架构的一致性

UE5 在核心架构上延续了 UE4 的设计理念，包括：

• 编辑器（Unreal Editor）：两者使用相同的编辑器框架，熟悉 UE4 的开发者可以零学习成本上手
• 蓝图系统（Blueprint）：可视化编程系统保持高度兼容，UE4 的蓝图资产可直接在 UE5 中使用
• C++ 框架 ：核心类结构和 API 设计高度相似，如 AActor、APawn、AController 等基础类一脉相承
• 物理引擎（Chaos）：UE5 中的 Chaos Physics Engine 实际上是 UE4 中实验性物理系统的正式化
• 音频引擎：UE4 使用内置音频引擎（SoundCue 节点图），UE5 引入的 MetaSound 提供原生模块化音频脚本

这种设计策略使 UE4 项目可以较为平滑地迁移到 UE5，约 80-90% 的既有代码和资产可直接复用。但 UE5 引入了多项突破性新技术，构成了一条明显的技术鸿沟。

迁移注意事项

• UE4 项目迁移至 UE5 时，需注意部分弃用（Deprecated）的 API 和模块
• 某些 UE4 第三方插件可能尚未适配 UE5，迁移前应确认依赖
• C++ 模块编译顺序和依赖管理在 UE5 中有所优化

---

二、渲染技术：两大核心技术跨越

2.1 Nanite 虚拟化几何体

UE4 时代：依赖手动创建 LOD（Level of Detail）多级模型，美术工作量大，且 LOD 层级切换时容易出现视觉跳变。

UE5 解决方案：Nanite 是革命性的虚拟微多边形几何体系统，将高精度模型的处理提升了一个数量级。

特性	UE4	UE5 (Nanite)
高精度模型	需手动创建 LOD	直接导入，无需 LOD
多边形数量	百万级上限（通常 1-5M）	亿级甚至数十亿
渲染策略	传统光栅化，预设 LOD	虚拟化自动按像素剔除
LOD 跳变	层级切换有视觉断裂	像素级过渡，无跳变
纹理压缩	ASTC/BC7 等标准格式	支持 Nanite 专用压缩
光线追踪兼容性	需手动烘焙	与 Ray Tracing 部分兼容

技术原理详解：

Nanite 的核心是**层次化几何结构（Hierarchical ZBinning）与软件光栅化（Software Rasterization）**的结合：

1. 虚拟化几何：Nanite 将输入的高精度模型压缩为层次化的 Cluster，每个 Cluster 包含不同细节层次的数据，渲染时根据屏幕投影面积智能选择精度
2. 按需加载：只加载当前视角可见的精度层级，显存压力大幅降低
3. 软件光栅化：Nanite 采用 CPU 侧软件光栅化处理三角形簇，在 GPU 受限时可作为降级方案
4. 材质简化：Nanite 支持材质穿孔（Masked Material）但有限制，PBR 表面处理有专门的路径

启用 Nanite 的两种方式：

方式一：编辑器界面操作（最常用）

1. 在内容浏览器中选中目标 Static Mesh 资产
2. 双击打开网格编辑器
3. 在工具栏菜单中找到 Nanite 选项卡
4. 点击 "启用 Nanite"（Enable Nanite）按钮
5. 引擎自动进行三角面简化处理，显示处理进度条

处理完成后，该网格体左下角会显示一个绿色 Nanite 图标，表示已启用。
方式二：C++ 代码启用

在运行时或编辑器工具中通过代码启用 Nanite：

// UE5 C++ 启用 Nanite
#include "Engine/StaticMesh.h"
#include "Engine/StaticMeshEditorData.h"

void EnableNaniteForMesh(UStaticMesh* StaticMesh)
{
    if (!StaticMesh) return;

    // 启用 Nanite 设置
    StaticMesh->NaniteSettings.bEnabled = true;

    // Nanite 配置完成后，引擎会自动处理后续重建流程
    StaticMesh->NaniteSettings.bEnabled = true;

    // 触发编辑器刷新（PostEditChange 会自动触发 Nanite 资源重建）
    // 无需手动调用 SetFlags 或 MarkPackageDirty
    StaticMesh->PostEditChangeProperty(nullptr);

    UE_LOG(LogTemp, Log, TEXT("Nanite enabled for mesh: %s"), *StaticMesh->GetName());
}

UE4 等效操作（手动 LOD 创建）：

// UE4 手动创建 LOD（已废弃，UE5 推荐使用 Nanite）
void CreateLODsForMesh(UStaticMesh* StaticMesh)
{
    if (!StaticMesh) return;

    // 设置 LOD 数量（UE4 默认最多 8 级）
    StaticMesh->SetLODCount(4);

    // UE4 中每个 LOD 级别需要手动烘焙光照贴图
    // 迁移到 UE5 后，这些工作流不再需要
}

Nanite 核心渲染伪代码：

// Nanite 核心渲染循环（简化伪代码）
void RenderNaniteMesh(FSceneView& View, const FNaniteSceneProxy* Proxy)
{
    // 1. 获取 Nanite 代理的层次化 Cluster 数据
    const TArray<FNaniteCluster>& Clusters = Proxy->GetClusters();

    // 2. 遍历每个 Cluster，按屏幕空间覆盖率决定 LOD 精度
    for (const FNaniteCluster& Cluster : Clusters)
    {
        // 3. 视锥裁剪：剔除不在相机视锥内的 Cluster
        if (!IsClusterInViewFrustum(Cluster, View))
            continue;

        // 4. 屏幕覆盖率计算：决定使用哪个 LOD 层级
        float ScreenCoverage = CalculateScreenCoverage(Cluster, View);
        int32 TargetLOD = SelectLOD(ScreenCoverage);

        // 5. 按需流式加载虚拟纹理（Virtual Texture）
        if (ShouldStreamTexture(Cluster, TargetLOD))
        {
            StreamVirtualTexturePage(Cluster, TargetLOD);
        }

        // 6. 渲染选定的 LOD 层级
        RenderCluster(Cluster, TargetLOD);
    }
}

性能影响：

• 在高精度场景（数亿多边形）中，Nanite 可将渲染 draw call 减少 90% 以上
• 显存峰值取决于视角内可见的 Cluster 数量，典型场景 2-4GB
• 建议最小 GPU 为 RTX 2070 / RX 5700 同级，实际需求因场景复杂度差异较大

实际应用场景：

• 影视级高精度角色和环境（如《黑客帝国：觉醒》展示）
• 建筑可视化项目中的 BIM 模型导入
• 虚拟制片中的 LED 体积拍摄

⚠️ Nanite 限制与注意事项：

• 不支持蒙皮网格体（Skeletal Mesh）在 UE5.0-5.2，但 UE5.3+ 已支持部分蒙皮网格体 Nanite
• 不支持半透明材质：需要使用 Two Sided 或 Masked 模式
• 不支持某些节点：World Position Offset、DBuffer Decals、Translucency after DOF 等
• 不支持多个 UV 通道：Nanite 仅使用前两个 UV 通道

2.2 Lumen 全动态全局光照

UE4 时代：依赖预烘焙光照（Lightmass），实时动态光照能力有限，白天/夜晚切换需要重新烘焙。

UE5 解决方案：Lumen 提供全动态全局光照系统，支持任意动态光源与几何变化的实时 GI。

特性	UE4	UE5 (Lumen)
光照类型	预烘焙为主	实时动态 + 软件/硬件追踪
光线追踪	需手动开启 Ray Tracing	可选硬件追踪加速
间接光照	需烘焙 Lightmap	无需烘焙，实时计算
阴影质量	依赖 Shadowmap	无穷远处软阴影
天空光照	静态或烘焙	动态天空遮挡
材质反馈	间接光照更新慢	材质变化实时反馈

技术原理详解：

Lumen 采用了多级探测缓存（Multi-Level Probe Cache）与软件/硬件混合追踪的架构：

1. 探测网格（Probe Grid）：场景中布置多层稀疏探测点，每层间距不同（近密远疏），探测点存储场景光照信息
2. 深度缓存探测（Depth Cached Probes）：针对半透明物体和非直射光面，Lumen 使用深度感知的探测方式减少漏光
3. 追踪模式 ：
   • Software Mode：纯软件实现，兼容所有 GPU，但性能较低，适合中端硬件
   • Hardware Ray Tracing：利用 DXR/RTX 加速，性能更高，适合 RTX 系列显卡
4. 无穷远阴影（Infinite Shadow）：Lumen 对远距离物体使用屏幕空间射线追踪，避免远处阴影失真

启用 Lumen 的操作流程：

方式一：编辑器界面操作（项目级设置）

1. 点击菜单栏 编辑 → 项目设置
2. 在左侧搜索栏输入 "Lumen"
3. 找到 Rendering → Lumen 配置项
4. 勾选 "Lumen 启用"（Project Settings → Rendering → Lumen → Enabled）
5. 在 "Lumen 追踪精度" （Trace Budget）中选择质量档位：
   • Low（低：移动端或性能敏感项目）
   • Medium（中：默认推荐）
   • High（高：高质量场景）
   • Epic（史诗：离线渲染品质）
     方式二：C++ / Blueprint 配置

// UE5 C++ 配置 Lumen
#include "Kismet/GameplayStatics.h"

void ConfigureLumenSettings()
{
    // Lumen 配置推荐通过 Console Variables 或 DefaultEngine.ini 设置
    // 示例 Console Variable 设置：

    // 启用 Lumen
    if (GEngine)
    {
        // 运行时设置 Console Variable
        GEngine->Exec(GetWorld(), TEXT("r.Lumen.Enable 1"));

        // 方式二：通过 IConsoleManager 脚本化设置
        // IConsoleManager::Get().FindConsoleVariable(TEXT("r.Lumen.Enable"))->Set(1);

        // 注意：部分 Lumen 设置需要在项目启动时配置，不支持热切换
        // 推荐在 DefaultEngine.ini 中统一配置
    }
}

推荐做法：通过 DefaultEngine.ini 配置

在 Config/DefaultEngine.ini 中添加：

[/Script/Engine.RendererSettings]
r.Lumen.Enable = 1
r.Lumen.TraceBudgetPerFrameMultiplier = 0.5
r.Lumen.HardwareRayTracing = 1
r.Lumen.ScreenProbeGather.StochasticGather = 1

; Software Mode（无 RTX 显卡）
; r.Lumen.HardwareRayTracing = 0

; 追踪精度设置（数值越大质量越高，性能消耗越大）
; r.Lumen.TraceBudgetPerFrameMultiplier = 1.0

UE4 等效操作（Lightmass 烘焙）：

// UE4 中需要烘焙 Lightmap（UE5 Lumen 不再需要）
void BakeLightmaps(UWorld* World)
{
    // UE4 烘焙流程：
    // 1. 编辑器中手动触发 Lightmass 烘焙
    // 2. 等待烘焙完成（大型场景可能需要数小时）
    // 3. 烘焙后无法实时修改光源位置
    // 4. 场景中任何几何变化都需要重新烘焙

    // 典型烘焙参数设置
    FLightmassParameters Params;
    Params.StaticLightingLevelScale = 1.0f;
    Params.NumIndirectLightingBounces = 3;
    Params.TerrainShadowQuality = 3;

    // 烘焙完成后，光照信息存储在 Lightmap 中
    // 修改任意光源 → 重新烘焙 → 等待 → 验证
    // 整个迭代周期在 UE4 中可能长达 30 分钟到数小时
}

工作流对比：

步骤	UE4（Lightmass）	UE5（Lumen）
初始设置	配置 Lightmass 参数 → 等待烘焙	启用 Lumen → 立即可用
调整主光源位置	修改 → 等待烘焙 30 分钟 → 验证	修改 → 即时看到效果
白天/夜晚切换	两套完整烘焙 → 运行时插值	无需烘焙，直接运行时切换
动态物体遮挡	烘焙后被忽略	实时反映（动态物体遮挡 GI）
迭代效率	低（每次调整都需等待）	高（所见即所得）

2.3 虚拟阴影贴图（Virtual Shadow Maps）

UE5 独有技术，作为 Lumen 动态光照系统的补充：

• 问题：UE4 中远距离物体阴影分辨率急剧下降（Shadow Cascade 远端精度不足）
• 解决方案：Virtual Shadow Maps 将阴影拆分为多个固定像素预算的 Virtual Page，动态分配阴影精度
• 效果：在开放世界中，100 米外的角色仍能保有清晰轮廓，不出现像素化或消失

启用方式：

; DefaultEngine.ini
[/Script/Engine.RendererSettings]
r.Shadow.Virtual.Enable = 1
r.Shadow.PerObject.Cascades = 4
r.Shadow.MaxShadowResolution = 4096

---

三、性能优化：多核与内存

3.1 多线程处理

方面	UE4	UE5
CPU 利用率	一般，多核优化有限	增强多线程，Task Graph 优化
资源加载	单线程为主（FStreamableManager）	多线程并行，智能预取
内存管理	标准引用计数	智能资源管理，新增垃圾回收优化
加载速度	较慢，尤其大型开放世界	显著提升，配合 Streaming 改进
IO 吞吐	标准 async IO	可配置异步 IO 吞吐量上限

UE5 在多核 CPU 利用率上有显著提升，通过改进的 Task Graph 系统，可以更高效地利用现代 8 核+ 处理器。

关键改进点：

• 音频线程解耦：音频处理不再阻塞主线程，音频 tick 完全独立
• Physics Tick 独立化：物理模拟可在固定时间步长下独立运行
• 渲染线程优化：减少渲染命令提交延迟，提升帧率稳定性

3.2 世界分区（World Partition）

UE4：大型开放世界需要手动分块管理（Portal Level Streaming），开发者需自行管理关卡边界和数据加载逻辑。

UE5：内置世界分区（World Partition）系统，重新定义了大型项目管理方式。

核心特性：

• 自动网格划分（Grid-Based World Partitioning）：引擎自动将世界划分为可配置的网格单元（如 1x1 km），无需手动管理分块
• 按需动态加载（On-Demand Loading）：运行时只加载玩家周围区域，大幅降低内存占用（典型开放世界可从 32GB+ 降到 8-16GB）
• Data Layer 数据层系统 ：
  • 支持同一区域多个版本（如白天/夜晚、开发版/发布版）
  • 每个 Data Layer 可独立加载/卸载
  • 适合 A/B 测试和关卡编辑协作文档管理
• LoD 地形系统（World Partition Land Mass）：地形支持分层 LOD，地物随距离自动简化
• 多人协作支持：World Partition 原生支持多人协同编辑，多人可同时编辑不同网格区域

开发效率提升：

• UE4 时代，开放世界地图通常需要 1-2 人的专职 Level Designer 管理加载流
• UE5 World Partition 将这一工作近乎自动化，让设计师专注内容而非技术管道

World Partition 配置流程：

创建 World Partition 地图的操作步骤

1. 新建地图 ：文件 → 新建级别 → 选择 "开放世界" 模板
   • UE5 会自动创建一个启用 World Partition 的空白地图
2. 配置网格大小 ：在世界详情（World Details）面板中
   • World Partition → Grid Size：设置网格划分精度（建议 1x1 km）
   • World Partition → Enable Streaming：启用运行时流式加载
3. 加载/卸载区域 ：编辑器工具栏 → World Partition → 加载区域
   • 使用矩形选择工具圈选需要编辑的区域
   • 未加载区域为灰色，显示"仅运行时加载"
4. 运行时加载控制：

// UE5 World Partition 运行时加载控制
#include "Engine/WorldPartition.h"

void AMyPlayerController::SetupWorldPartitionStreaming()
{
    UWorld* World = GetWorld();
    if (!World) return;

    // 获取 World Partition 组件
    UWorldPartition* WP = World->GetWorldPartition();
    if (!WP) return;

    // 设置加载半径（米）
    // UE5 WorldPartition 运行时流送通过 Streaming Distance 控制
    // 可通过 WorldSettings 的 bUseStreamingAutoLODBias 或
    // 运行时 Hash 的 Streaming Distance 配置加载范围
    // 具体 API 请查阅 UE5 官方 WorldPartition 文档
}

UE4 等效操作（Level Streaming 手动管理）：

// UE4 手动管理 Level Streaming
void AMyGameMode::SetupLevelStreaming()
{
    UWorld* World = GetWorld();

    // 手动创建流送关卡引用
    TArray<FName> LevelNames = {
        TEXT("Persistent"),
        TEXT("Zone1_A"),
        TEXT("Zone1_B"),
        TEXT("Zone2_A"),
        // ... 每个区域都需要手动添加
    };

    for (const FName& LevelName : LevelNames)
    {
        FLatentActionInfo LatentInfo;
        UGameplayStatics::LoadStreamLevel(
            this,
            LevelName,
            true,  // bMakeVisibleAfterLoad
            false, // bShouldBlockOnLoad
            LatentInfo
        );

        // 手动设置每个关卡的加载优先级
        // 需要在关卡蓝图中手动配置触发Volume
        // 多人协作时容易出现关卡冲突
    }
}

Data Layer 数据层操作流程：

1. 在 World Details 面板 → Data Layers 选项卡 → 创建新数据层
2. 常见用法示例：
   • DawnEnvironment 层：白天专用光照和植被
   • NightEnvironment 层：夜晚专用光照和灯笼
   • DebugContent 层：仅开发时显示的调试物体
3. 运行时切换数据层：

// UE5 运行时切换 Data Layer
#include "Engine/WorldPartition.h"
#include "Engine/DataLayer/DataLayerManager.h"

void AMyGameMode::ToggleDayNightEnvironment()
{
    UDataLayerManager* DataLayerMgr = UDataLayerManager::Get(GetWorld());
    if (!DataLayerMgr) return;

    FName DawnLayerName = TEXT("DawnEnvironment");
    FName NightLayerName = TEXT("NightEnvironment");

    // 卸载白天层，加载夜晚层
    DataLayerMgr->SetDataLayerInstanceRuntimeState(
        DawnLayerName,
        EDataLayerRuntimeState::Unloaded
    );

    DataLayerMgr->SetDataLayerInstanceRuntimeState(
        NightLayerName,
        EDataLayerRuntimeState::Loaded
    );
}

3.3 IO 优化与资产流送

UE5 的 IO 系统引入了多项改进：

• 可配置 IO 带宽 ：通过 IoStoreSettings，开发者可调整 Async IO 吞吐量上限
• 可中断加载（Interruptible File Loading）：加载过程可被高优先级请求打断
• Pak 文件改进：UE5 的 IoStore 支持更好的增量更新和热更新方案

// UE5 IO 配置示例
void ConfigureIO()
{
    // 在 DefaultEngine.ini 中配置
    // [Core.System]
    // IoStoreSettings=...
}

---

四、角色创作：MetaHuman 与动画系统

4.1 MetaHuman Creator

UE4：需要手动建模、绑定、雕刻，完整的 AAA 级数字角色制作周期通常为 4-12 周。

UE5：引入 MetaHuman Creator，云端创建高质量数字人类。

技术规格：

• 云端渲染驱动的面部采集，确保毛孔级皮肤细节
• 预置超过 200 个可混合的表情 Morph Target，覆盖 FACS 表情系统
• 完整的身体骨骼绑定，兼容 UE5 的 Motion Matching
• 基于 RTX 加速的头发渲染，每根发丝物理模拟
• 眼动追踪系统（Eye Tracking）原生支持

工作流程：

1. 在 MetaHuman 网站调整角色参数（种族、年龄、发型、妆容等）
2. 下载完整 UE5 角色模板（包含 Skeleton、Morph、Physics Asset）
3. 导入项目后，AnimBP 和 Control Rig 已预绑定
4. 支持使用 Live Link 驱动面部动画

性能消耗：

• 单个 MetaHuman 角色运行时消耗：约 2-4ms/帧（含动画和渲染）
• 显存占用：约 200-500MB（取决于 LOD 和毛发精度）
• 推荐用于过场动画、实时录制、VTuber 应用

4.2 Motion Matching 动画系统

UE5 引入的 Motion Matching 是对 UE4 动画状态机的重大升级：

方面	UE4 (Animation State Machine)	UE5 (Motion Matching)
动画切换	固定状态过渡，僵硬	基于数据库匹配的动态过渡
动画资产量	有限	需要大量动画片段（通常 1-2 小时）
响应速度	延迟较高	实时响应输入，流畅自然
代码依赖	逻辑代码复杂	减少蓝图中状态逻辑代码量
调试工具	一般	专用 Motion Matching 可视化工具

技术原理：

Motion Matching 建立一个动画数据库（Pose Vector），运行时根据角色当前状态（速度、加速度、朝向）和输入意图，在数据库中搜索最匹配的下一帧动画序列。通过平滑插值消除帧间跳变，实现自然的动作过渡。

适用场景：开放世界 RPG、动作冒险、多人对战等需要自然角色运动的项目。

4.3 Control Rig 与 FK/IK 绑定

UE5 的 Control Rig 系统提供程序化 IK 动画控制：

• 支持多段 IK：手指、手臂、腿部多段 IK 无需手动编写节点
• Rig Graph 可视化：Blueprint 风格的节点图表编辑
• 与 MetaHuman 集成：MetaHuman 角色自带预置 Control Rig，可直接驱动面部和身体

Control Rig 自定义节点 C++ 示例：

// UE5 自定义 ControlRig 节点（脚部 IK 计算）
// 文件: RigUnit_GetFootTargetAngle.h
// 需在 .Build.cs 中添加: AnimationCore

#pragma once
#include "RigUnit_GetFootTargetAngle.generated.h"

/**
 * 计算脚部目标朝向的自定义 ControlRig 节点
 * 用于程序化角色动画中的脚部 IK 适配
 */
USTRUCT(DisplayName = "Get Foot Target Angle")
struct FMyAnimationRig_API FRigUnit_GetFootTargetAngle : public FRigUnit
{
    GENERATED_BODY()

    RIGVM_METHOD()
    virtual void Execute() override;

    // 输入：骨骼在 Rig Space 中的速度
    UPROPERTY(meta = (Input))
    FVector RigSpaceVelocity;

    // 输入：目标地面法线
    UPROPERTY(meta = (Input))
    FVector GroundNormal;

    // 输出：脚部目标 Z 轴旋转角度（度）
    UPROPERTY(meta = (Output))
    float FootTargetZAngle;
};

// 文件: RigUnit_GetFootTargetAngle.cpp
#include "RigUnit_GetFootTargetAngle.h"
#include "Animation/RigCurveContainer.h"
#include "Math/Rotation.h"

RIGVM_METHOD()
void FRigUnit_GetFootTargetAngle::Execute()
{
    URigHierarchy* Hierarchy = ExecuteContext.Hierarchy;
    if (!Hierarchy) return;

    // 计算速度在地面法线方向上的投影
    FVector ProjectedVelocity = FVector::ProjectOnToPlane(
        RigSpaceVelocity,
        GroundNormal
    );

    // 根据投影速度方向计算脚部旋转
    if (!ProjectedVelocity.IsNearlyZero(0.01f))
    {
        // 计算朝向角
        float Angle = FMath::Atan2(
            ProjectedVelocity.Y,
            ProjectedVelocity.X
        );

        // 转换为度数并限制范围
        FootTargetZAngle = FMath::RadiansToDegrees(Angle);
        FootTargetZAngle = FMath::Fmod(FootTargetZAngle + 180.0f, 360.0f) - 180.0f;
    }
    else
    {
        FootTargetZAngle = 0.0f;
    }
}

---

五、粒子系统与Niagara

UE4：Cascade 粒子系统

UE4 的 Cascade 是早期遗留的粒子系统，已停止新功能开发：

• 模块化设计，但扩展性有限
• 数据驱动通过 UParticleSystem 资源
• GPU 粒子支持有限，最大粒子数受限于 MAX_PARTICLES 宏

UE5：Niagara 视觉化脚本粒子系统

Niagara 是 UE5 重写的现代粒子系统，采用模块化架构：

特性	Cascade	Niagara
架构	遗留系统	全新模块化架构
脚本化	有限	完全程序化（Niagara Script）
粒子数量	10K-50K 级	100K-数百万级
数据解耦	粒子数据与系统耦合	粒子数据可单独存储
跨项目复用	困难	可导出为模板

Niagara vs Cascade 代码创建对比：

// UE4 Cascade 粒子系统创建
UParticleSystem* CreateCascadeEffect(UObject* Outer)
{
    // UE4 创建 Cascade 粒子
    UParticleSystem* ParticleSystem = NewObject<UParticleSystem>(Outer);
    ParticleSystem->bUseFullPrecision = true;
    ParticleSystem->LODDistanceCheckTime = 0.5f;

    // ⚠️ Cascade 代码化操作复杂，通常推荐在编辑器内可视化编辑
    // UParticleModule 为 Cascade 基类，代码化模块创建不作为常规用法
    return ParticleSystem;
}

// UE5 Niagara 粒子系统创建
#include "NiagaraSystem.h"
#include "NiagaraComponent.h"

UNiagaraSystem* CreateNiagaraEffect(UObject* Outer)
{
    // UE5 创建 Niagara 粒子
    UNiagaraSystem* NiagaraSystem = NewObject<UNiagaraSystem>(Outer);

    // Niagara 支持完全程序化脚本
    // 可导出为独立资产在项目间复用
    FNiagaraSystemUpdateContext UpdateCtx;
    UpdateCtx.AddSystem(NiagaraSystem);

    // 支持百万级粒子数量
    // 注意：SetMaxSimCapacity 控制模拟粒子容量上限
    // 实际粒子数受 NiagaraSim 的 CPU/GPU 模拟设置和硬件性能限制
    // NiagaraSystem->SetMaxSimCapacity(1000000);

    return NiagaraSystem;
}

适用场景：

• 大规模粒子效果（暴风雨、雪崩、人群）
• 程序化生成（程序化草地、植被散布）
• 复杂交互式粒子（角色死亡特效、液体交互）

---

六、C++ 代码差异与迁移

6.1 C++ 标准支持

特性	UE4	UE5
C++ 标准	C++14 为主（部分 C++17）	C++20 标准库完整支持
模块支持	早期实验性模块	原生模块化（import/module）
代码组织	模块化不足	模块化可复用，编译速度提升
元数据（Metadata）	UPROPERTY()	无变化，向后兼容
蓝图互操作	同上	无变化，向后兼容

UE5 的 C++20 支持使代码组织更加模块化：

• concepts、ranges 等 C++20 特性可直接使用
• 模块化编译（Module System）减少编译时间约 20-30%（大型项目）
• TObjectPtr<T> 替代原始 T* 指针，提供更好的 GC 兼容性和代码可读性

6.2 TObjectPtr 迁移：UE4 到 UE5 的必改项

UE5 官方推荐使用 TObjectPtr<T> 替代原始 UPROPERTY 指针，这是最重要的 C++ 迁移变更之一。

UE4 写法（已废弃警告）：

// MyCharacter.h - UE4 写法
#pragma once
#include "GameFramework/Character.h"
#include "MyCharacter.generated.h"

UCLASS()
class AMyCharacter : public ACharacter
{
    GENERATED_BODY()

public:
    // ❌ UE4 原始指针写法（编译时会有弃用警告）
    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    UStaticMeshComponent* WeaponMesh;

    UPROPERTY(EditAnywhere, BlueprintReadWrite)
    UAnimationAsset* IdleAnimation;

    UPROPERTY(VisibleAnywhere, Category = "Gameplay")
    AController* OwningController;

protected:
    // ❌ 裸指针成员变量
    UCharacterMovementComponent* MovementComponent;
    USkeletalMeshComponent* MeshComponent;
};

UE5 推荐写法：

// MyCharacter.h - UE5 推荐写法
#pragma once
#include "GameFramework/Character.h"
#include "MyCharacter.generated.h"

UCLASS()
class AMyCharacter : public ACharacter
{
    GENERATED_BODY()

public:
    // ✅ UE5 TObjectPtr 写法（推荐）
    UPROPERTY(EditAnywhere, BlueprintReadWrite, meta = (DisplayName = "武器网格体"))
    TObjectPtr<UStaticMeshComponent> WeaponMesh;

    UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Animation")
    TObjectPtr<UAnimationAsset> IdleAnimation;

    UPROPERTY(VisibleAnywhere, Category = "Gameplay")
    TObjectPtr<AController> OwningController;

protected:
    // ✅ TObjectPtr 提供更好的 GC 兼容性和代码可读性
    UPROPERTY()
    TObjectPtr<UCharacterMovementComponent> MovementComponent;

    UPROPERTY()
    TObjectPtr<USkeletalMeshComponent> MeshComponent;
};

// MyCharacter.cpp
#include "MyCharacter.h"
#include "Components/CapsuleComponent.h"

void AMyCharacter::BeginPlay()
{
    Super::BeginPlay();

    // TObjectPtr 使用 .Get() 访问底层指针
    if (UCharacterMovementComponent* MoveComp = MovementComponent.Get())
    {
        MoveComp->MaxWalkSpeed = 600.0f;
    }

    // TObjectPtr 支持隐式转换为 bool（检查有效性）
    if (WeaponMesh)
    {
        WeaponMesh->SetCollisionEnabled(ECollisionEnabled::QueryOnly);
    }

    // ❌ 严禁手动 delete TObjectPtr 指向的对象！
    // 错误示例：delete WeaponMesh.Get(); // 会破坏 GC 状态！
}

迁移脚本工具（批量替换）：

# migrate_tobjectptr.py - 批量迁移脚本
import re
import os

def migrate_file(filepath):
    with open(filepath, 'r', encoding='utf-8') as f:
        content = f.read()

    # 匹配 UPROPERTY 中的原始指针类型（排除 TObjectPtr）
    # 替换规则：
    # UPROPERTY(...)\n    UClassName* → UPROPERTY(...)\n    TObjectPtr<UClassName>
    pattern = r'(UPROPERTY\s*\([^)]*\))\s*\n\s*(\w+)\s*(\*+)'

    def replace_func(match):
        prop = match.group(1)
        var_name = match.group(2)
        pointer = match.group(3)
        # 只有一个 * 才迁移（避免 TObjectPtr 双重迁移）
        if pointer.count('*') == 1:
            return f'{prop}\n    TObjectPtr<{var_name}>'
        return match.group(0)

    new_content = re.sub(pattern, replace_func, content)

    if new_content != content:
        with open(filepath, 'w', encoding='utf-8') as f:
            f.write(new_content)
        return True
    return False

# 使用示例
for root, dirs, files in os.walk('Source'):
    for file in files:
        if file.endswith('.h') or file.endswith('.cpp'):
            path = os.path.join(root, file)
            if migrate_file(path):
                print(f'Migrated: {path}')

6.3 模块依赖声明变化

UE5 优化了模块间的依赖声明方式。

UE4 .Build.cs 写法：

// MyProject.Build.cs - UE4
using UnrealBuildTool;

public class MyProject : ModuleRules
{
    public MyProject(ReadOnlyTargetRules Target) : base(Target)
    {
        // UE4 需要显式声明所有公共依赖
        PublicDependencyModuleNames.AddRange(
            new string[] {
                "Core",
                "CoreUObject",
                "Engine",
                "InputCore",
                "AIModule",
                // ...
            }
        );

        // 私有依赖（仅本模块内部使用）
        PrivateDependencyModuleNames.AddRange(
            new string[] {
                "RenderCore",
                "RHI",
            }
        );
    }
}

UE5 .Build.cs 写法：

// MyProject.Build.cs - UE5
using UnrealBuildTool;

public class MyProject : ModuleRules
{
    public MyProject(ReadOnlyTargetRules Target) : base(Target)
    {
        // UE5 推荐写法：按需添加，编译更快
        // UE5 自动处理公共依赖的传递闭包

        PublicDependencyModuleNames.AddRange(
            new string[] {
                "Core",
                "CoreUObject",
                "Engine",
                "GameplayTasks",
            }
        );

        // 添加 AnimationCore（ControlRig 等需要）
        PublicDependencyModuleNames.Add("AnimationCore");

        // UE5 新增模块化支持
        // 可以使用 C++20 import/module 语法
    }
}

6.4 UPROPERTY 元数据标签增强

UE5 新增了多个实用的 UPROPERTY 元数据标签。

// UE5 新增元数据标签示例
UCLASS()
class AMyActor : public AActor
{
    GENERATED_BODY()

public:
    // ✅ 新增：显示名称（蓝图编辑器中的中文显示）
    UPROPERTY(EditAnywhere, meta = (DisplayName = "生命值"))
    float Health;

    // ✅ 新增：工具提示（悬停时显示）
    UPROPERTY(EditAnywhere, meta = (
        ToolTip = "当前角色的生命值，范围 0-100"))
    float CurrentHealth;

    // ✅ 新增：仅显示增量变化（用于性能敏感数值）
    UPROPERTY(EditAnywhere, meta = (ClampMin = "0", ClampMax = "100"))
    float Stamina;

    // ✅ 新增：分类标题（蓝图编辑器中分组显示）
    UPROPERTY(EditAnywhere, Category = "Combat|Weapon")
    float AttackDamage;

    // ✅ 新增：允许在不同蓝图中覆写
    UPROPERTY(EditDefaultsOnly, BlueprintGetter = GetArmorValue)
    float Armor;
};

6.5 Gameplay Ability System (GAS) 代码差异

GAS（Gameplay Ability System）在 UE4 和 UE5 中的核心 API 保持兼容，但 UE5 进行了大量优化。

// UE5 GAS 组件声明（推荐写法）
#include "GameplayAbilitySystemComponent.h"
#include "AbilitySystemInterface.h"
#include "MyCharacter.generated.h"

UCLASS()
class AMyCharacter : public ACharacter, public IAbilitySystemInterface
{
    GENERATED_BODY()

public:
    // ✅ UE5 推荐：使用 TObjectPtr
    UPROPERTY(VisibleDefaultsOnly, Category = "GAS")
    TObjectPtr<UGameplayAbilitySystemComponent> AbilitySystemComponent;

    // 属性集
    UPROPERTY()
    TObjectPtr<UMyAttributeSet> AttributeSet;

    // IAbilitySystemInterface 实现
    virtual UAbilitySystemComponent* GetAbilitySystemComponent() const override
    {
        return AbilitySystemComponent.Get();
    }
};

---

七、蓝图系统操作流变化

7.1 蓝图接口创建流程

UE5 要求蓝图接口必须显式编译才能在运行时被识别，这是最常见的踩坑点之一。

UE5 蓝图接口正确创建流程：

步骤一：创建接口

1. 内容浏览器 → 右键 → Blueprint 界面（Blueprint Interface）

2. 命名为 BPI_Interactable

3. 双击打开编辑器
   步骤二：定义函数

4. 在左侧面板 函数（Functions） 区域点击 +

5. 命名函数（如 OnInteract）

6. 设置输入输出参数

7. ⚠️ 必须：点击工具栏 "编译"（Compile）按钮

8. ⚠️ 必须：点击工具栏 "保存"（Save）按钮

9. 关闭编辑器
   步骤三：在其他蓝图中使用

10. 打开需要实现接口的蓝图

11. 右键 → 接口 → 添加类设置（Add Interface）

12. 选择 BPI_Interactable

13. 在 我的蓝图 → 接口 中找到 OnInteract

14. 实现函数逻辑

❌ 常见错误流程（导致接口不工作）：

错误流程：
1. 创建接口
2. 定义函数（但没编译！）
3. 直接在其他蓝图中调用
4. 运行时发现事件无法触发 ❌

正确流程：
1. 创建接口
2. 定义函数
3. 点击编译 ✅
4. 点击保存 ✅
5. 关闭编辑器
6. 再在其他蓝图中调用
7. 运行时正常工作 ✅

接口蓝图函数签名不一致问题：

// 定义接口时，C++ 侧需要精确匹配参数
// 错误示例：参数类型不匹配
// BPI_Interactable 接口定义：OnItemUsed(ItemID: int32)
// 实现蓝图却使用：OnItemUsed(ItemID: float) ← 类型不匹配！

// ✅ 正确做法：确保类型完全一致
// 接口：OnItemUsed(ItemID: int32)
// 实现：OnItemUsed(ItemID: int32) ← 完全一致

7.2 蓝图代码规范与审计

UE5 编辑器内置了资产分析和调试工具，用于检查蓝图质量。

UE5 内置工具使用方式：

1. 在内容浏览器中右键点击资产或文件夹
2. 引用查看器（Reference Viewer）：可视化依赖关系图
3. Size Map：可视化资产大小分布
4. Audit（审计）：查看资产统计（面数、Draw Call、内存占用）
5. Blueprint Debugger ：在 窗口 → 开发者工具 中调试蓝图执行
   对于团队代码规范，Epic 官方提供了命名规范指南，建议参考制定团队标准

常见代码规范检查项：

问题类型	示例	修复建议
音频采样率	24000 Hz（不标准）	改为 22050 Hz 或 44100 Hz
蓝图命名规范	character_1	使用 BP_Character_Player
松散节点	未连接的节点	删除或连接
纹理尺寸	超过 8192 像素	压缩或降低分辨率
循环引用	AB 之间互相引用	重构设计解耦

7.3 蓝图执行效率优化

UE5 的蓝图编译器对执行效率进行了优化，部分优化在 UE4 中需要手动处理。

UE4 vs UE5 蓝图性能对比：

操作	UE4	UE5
循环内调用函数	每次都查找函数表	内联优化，减少查找开销
分支判断	每次评估条件	分支预测优化
数组操作	逐元素处理	批量处理优化
事件调度	每次查找委托链	缓存优化

优化建议：

UE5 蓝图性能优化技巧：
1. 频繁调用的函数 → 标记为 "Pure"（无副作用）
2. 大数组遍历 → 使用 "For Each Loop with Break" 提前退出
3. 条件判断 → 避免在循环内重复计算相同的条件
4. 变量缓存 → 重复使用的值存储到局部变量
5. Tick 事件 → 只在必要时启用，降低频率

7.4 Animation Layer Interface 操作流程

UE5 的 Animation Layer Interface 是模块化动画的核心工具。

创建 Animation Layer Interface 步骤：

1. 内容浏览器 → 右键 → 动画 → Animation Layer Interface
2. 命名为 AL_I_UpperBody
3. 定义接口函数（如 OnUpperBodyEvaluate）
4. 编译保存

在 AnimBP 中使用：

1. 打开角色 AnimBP
2. 类设置（Class Settings） → 接口（Interfaces） → 添加 AL_I_UpperBody
3. 在 AnimGraph 中：
   • 创建 Layered Bone Blend 节点
   • 将 AL_I_UpperBody 作为叠加层接入
4. 创建实现该接口的 AnimLayer（如 AnimLayer_UpperBody）
5. 在 AnimLayer 中实现上半身动画逻辑
6. 最终效果：下半身保持基础运动，上半身可独立播放射击、持物等动作

---

八、资产迁移工作流

8.1 UE4 项目迁移至 UE5 的完整流程

当需要将 UE4 项目迁移到 UE5 时，推荐以下操作流程：

阶段一：准备工作

1. 备份原 UE4 项目（复制整个文件夹）
2. 在 Epic Launcher 中安装目标 UE5 版本（如 5.4）
3. 安装项目依赖的第三方插件（确认已支持 UE5）
   阶段二：迁移资产

方式一：使用官方 Migrate 工具（推荐）

1. 在 UE4 编辑器中打开项目
2. 内容浏览器 → 全选需要迁移的资产（按住 Shift 多选）
3. 右键 → 资产操作（Asset Actions） → 迁移（Migrate...）
4. 在弹出的对话框中选择目标 UE5 项目的 Content 目录
5. 引擎自动分析依赖项，拷贝所有相关资产
6. 等待迁移完成
   方式二：通过 Asset Registry 脚本迁移

// UE5 C++ 批量迁移资产
#include "AssetRegistryModule.h"
#include "AssetToolsModule.h"

void MigrateAssetsBetweenProjects(
    const FString& SourceProject,
    const FString& TargetProject,
    const TArray<FSoftObjectPath>& AssetsToMigrate)
{
    IAssetRegistry& Registry = FModuleManager::LoadModuleChecked<FAssetRegistryModule>(
        "AssetRegistry"
    ).Get();

    IAssetTools& AssetTools = FModuleManager::LoadModuleChecked<FAssetToolsModule>(
        "AssetTools"
    ).Get();

    // 导出资产
    TArray<FAssetData> AssetDatas;
    for (const FSoftObjectPath& Path : AssetsToMigrate)
    {
        FAssetData Data;
        if (Registry.GetAssetByObjectPath(Path, Data))
        {
            AssetDatas.Add(Data);
        }
    }

    // UE5 推荐使用编辑器内置 Migrate 工具进行跨项目迁移
    // 脚本方式迁移复杂且容易遗漏依赖项
    UE_LOG(LogTemp, Warning,
        TEXT("Use Editor Migrate tool for cross-project migration"));
}

方式三：导出 FBX / 纹理再导入

适用于仅迁移静态网格和纹理：

1. 在 UE4 编辑器中选中资产
2. 右键 → 资产操作 → 导出（Export）
3. 选择格式（FBX / PNG / TGA）
4. 在 UE5 编辑器中执行：文件 → 导入到项目
5. ⚠️ 注意：此方式会丢失蓝图连接、光照烘焙数据、自定义属性

8.2 版本不兼容问题的处理

问题：UE5.4.4 的资产导入到 UE5.1.1 失败。

原因 ：每个引擎版本的 .uasset 格式可能有差异，新版本可能包含旧版本不认识的字段。

解决方案：

方法	适用场景	优缺点
Asset Migrate 工具	资产迁移（引擎版本相近）	✅ 保留所有依赖关系；⚠️ 可能失败
导出 FBX / 纹理	仅静态网格和贴图	✅ 通用兼容；⚠️ 丢失蓝图数据
升级中间格式	VRM / glTF 等格式	✅ 保留模型数据；⚠️ 需重新配置
手动重建	少量关键资产	✅ 质量最高；⚠️ 工作量大

8.3 VRM / MetaHuman 模型迁移注意事项

VRM4U 插件迁移问题（UE4 → UE5）：

问题现象 ：

将 UE4.24 中使用 VRM4U 导出的模型迁移到 UE5.3 后，Morph Target（变形目标）丢失。
根本原因 ：

VRM4U 插件在 UE4 和 UE5 间的数据格式不兼容。
解决方案：

1. 在 UE5.3 中重新安装最新版本的 VRM4U 插件
2. 重新导出 VRM 模型（不要直接使用 UE4 的导出文件）
3. 在 UE5 中重新导入 VRM
4. 验证 Morph Target 是否正常工作

---

九、授权与商业门槛

方面	UE4	UE5
版税门槛	首个 100 万美元收入免版税	首个 100 万美元收入免版税
基础费率	5%	5%
高收入超额费率	5%（无阶梯）	超过 100 万后按阶梯递增（最高约 5%）
商业模式	订阅制转永久制	订阅制转免费+版税
学习资源	成熟丰富（Epic 官方英文文档）	持续增加
社区支持	广泛，插件生态成熟	快速成长，新型工具持续发布
第三方插件	大量成熟插件（Marketplace）	持续增加，部分 UE4 插件已迁移

💡 注：Epic 在 2024 年宣布 UE5 采用免费使用 + 5% 版税模式（收入超过 100 万美元后），与 UE4 最后版本的商业模式基本一致。

---

十、应用场景与选型决策

何时选择 UE4？

• 项目目标为中低配置设备（如移动端、入门级 PC）
• 对稳定性和兼容性有高要求，不希望被引擎升级打断开发节奏
• 已有成熟的 UE4 项目和技术栈，迁移成本大于收益
• 硬件配置有限的开发环境（16GB 以下 RAM、GTX 1060 级 GPU）
• 需要使用成熟稳定的第三方插件（如 Vivox、Photon、Steamworks 集成等）
• 移动端或 WebGL 发布为主要目标

何时选择 UE5？

• 追求极致画质效果，高端 PC / 次世代主机为主要目标平台
• 项目需要 Nanite + Lumen 特性（影视化品质、虚拟制片）
• 开发开放世界 3A 级游戏
• 虚拟制片（LED Volume）、影视可视化项目
• 汽车可视化、数字孪生项目（需高精度模型实时渲染）
• 需要 MetaHuman 级别的高质量数字角色
• 有充足研发时间适应新工作流程

技术债务考量

因素	UE4 优势	UE5 优势
第三方插件	✅ 生态完整	⚠️ 部分缺失
学习曲线	✅ 资源丰富	⚠️ 新工具需额外学习
引擎稳定性	✅ 经过多年验证	⚠️ 仍在快速迭代
技术前沿	⚠️ 落后	✅ 行业领先
团队经验	⚠️ 需转换	⚠️ 需培养

---

十一、核心技术规格对比表

技术领域	UE4 (4.27)	UE5 (5.4+)
渲染管线	Forward / Deferred	Deferred（默认）+ Forward（可切换）
全局光照	Lightmass 烘焙	Lumen 实时动态
高精度几何	手动 LOD（LOD 0-4）	Nanite 虚拟化几何
阴影	Shadow Cascade（CSM）	Virtual Shadow Maps
光线追踪	需要 DXR 手动配置	原生 Lumen + Ray Tracing
粒子系统	Cascade（遗留）	Niagara（推荐使用）
动画系统	Animation State Machine	Motion Matching + AnimBP
开放世界	Level Streaming（手动）	World Partition（自动）
角色系统	手动制作流程	MetaHuman Creator
物理破坏	Chaos（实验性）	Chaos（正式化）
音频	Audio Engine	MetaSound + Audio Volumes
网络复制	Replicated Actor 模型	相似，Gameplay Net 优化
构建格式	Pak + UFS	IoStore + Oodle Compression
最小 GPU	GTX 970 级	RTX 2070 / RX 5700 建议

---

十二、参考资源

• Unreal Engine 5 官方文档
• Nanite 技术解析
• Lumen 全局光照
• MetaHuman Creator
• World Partition 指南
• Motion Matching 文档
• Niagara 粒子系统
• TObjectPtr 技术陷阱解析
• UE5 ControlRig C++ 自定义节点
• World Partition 实战配置
• 蓝图接口避坑指南

---

本文基于 2025-2026 年技术信息撰写，涵盖 UE4.27 与 UE5.4 版本对比，如有变动请以官方最新文档为准。