我真正开始认真做 UE 学习资料整理是在被同一个问题绊倒第三次之后。前两次都是半透明材质为什么在景深里不生效第三次是投掷物的抛物线算不准明明公式没错飞出去却总是偏差半个身位。每次都要重新翻聊天记录、翻浏览器书签、翻一堆命名毫无规律的截图文件夹最后靠记忆硬凑出答案。那段时间我才意识到问题不在我记性差而在于我从来没有把资料当成一个需要设计的东西去对待——它们只是一堆散落在硬盘上的文本和图片没有结构没有检索路径也没有上下文。这篇分享想聊的就是这件事怎么把 UE 相关的学习资料整理成一套能长期用、能快速检索、能直接复现的结构。它不打算教你如何从零学会虚幻引擎那是教程的活儿它只解决一个非常具体的问题——下次你再遇到帧率莫名其妙掉一半字符串和文本到底该用哪个倒影渐变怎么做才自然这类问题时能在三分钟之内翻到答案而不是重新踩一遍坑。刚入门、正在疯狂存资料却越存越乱的朋友适合看做了两年项目、笔记散落在各种地方的从业者也适合看。我下面写的东西全部来自我自己反复推翻重来的几轮实践包括那些踩过的坑和最后被证明没用的做法。1. 整理之前先想清楚这套资料到底为谁服务1.1 资料堆积的三个真实痛点我发现绝大多数人的 UE 资料库都会同时得三种病只是严重程度不同。第一种是找不到命名毫无语义全是截图 2023-08-15 143022.png或者新建文本文档 (7).txt搜索功能基本失效只能靠时间线回忆那次好像是去年冬天。第二种是看不懂。很多笔记只记结论不记前提比如写了一行用 After DOF 解决三个月后自己看着这行字完全懵——哪个材质哪个版本的引擎是解决不生效还是解决闪烁没有上下文的结论等于没有结论甚至比没有更糟因为它会诱导你在错误的前提下试错。第三种是复现不了。这是最要命的。你记得自己做过一个效果很好的平面反射倒影参数调得很舒服但当时的工程已经删了截图只拍了最终效果没拍参数面板于是那个效果就永远只存在于记忆里。我前后至少丢过五六个这样的效果每次重新调都要花掉一整个下午。这三个痛点对应的解法完全不一样找不到要靠命名规范和语义化索引看不懂要靠问题现象 环境版本 排查过程 结论的固定结构复现不了要靠最小复现工程。把它们混在一起处理就会变成把所有东西塞进一个大文件夹然后绝望。1.2 我的四层分类法试过七八种分类方式之后我最后稳定在四层结构上。这四层不是按知识领域分的渲染、动画、物理这种分法看着整洁但实际查的时候你根本不知道一个问题该归到哪一类而是按使用方式分的。层级名称内容形态使用场景单条体积L1速查卡一行结论 一行触发条件已经知道答案在哪只忘了细节1-3 行L2问题笔记现象、版本、排查步骤、结论、反例遇到新问题需要完整过程半页到两页L3最小复现工程只包含一个功能的工程需要验证或改造某个方案几十到几百 MBL4参考项目完整工程 目录结构说明要抄整体架构时GB 级关键在于L1 和 L2 必须分开。我以前习惯把速查卡写在笔记末尾结果真要速查的时候得先滚过两千字的排查过程非常反人类。分开之后L1 我用一个单独的 Markdown 文件按主题分块维护每个主题下面就是密集的一行行结论全部加粗关键参数扫一眼就能定位。L3 最小复现工程是最容易被忽略但价值最高的一层。做法很简单新建一个干净工程只放能复现这个效果的那一个关卡、一个材质、一个蓝图然后把它压缩存档命名里带上引擎版本。这样即使过两年引擎大版本升级导致行为变化你也有一个可以拿来对比的基线。我现在的习惯是每搞定一个调了超过半小时的效果就顺手抽一个最小工程出来压缩后大概几十兆成本很低。1.3 命名和版本标记的硬约定命名这件事我定过一堆规则最后只留下三条真正被执行下去的文件名格式统一为[引擎版本][领域]一句话结论.md例如[UE5.4][渲染]半透明材质需要在材质里设为BeforeDOF才会被景深影响.md。看着很长很蠢但搜索命中率极高而且不依赖任何工具。截图一律重命名规则是[领域]描述-日期.png批量重命名用系统自带的就行别为这个专门装软件。所有笔记开头必须写引擎版本写在第一行格式 环境UE 5.4.2 / Windows / 独显。这一行能省掉后面无数次的这是 5.0 还是 5.4 的笔记的困惑。注意不要用最新以后再看重要这种词做文件夹名。半年后你会有一堆叫重要的文件夹里面装着你已经想不起来为什么重要的东西。2. 环境和安装包把地基资料先归档2.1 引擎版本与安装包的管理取舍UE 的安装包管理有个很现实的矛盾新版本功能多但项目一旦开始就不能随便升。我的做法是每个长期项目锁死一个大版本同时保留一个最新稳定版用来试新功能硬盘上最多同时存在两个版本超过就删。安装引擎的时候有个选项特别值得说Editor symbols for debugging。勾上之后安装体积会暴增几十个 GB安装时间也长很多。它只在你要定位引擎崩溃、看 C 调用栈的时候有用。如果你只是做蓝图和普通 C 开发第一遍装的时候完全可以不勾等真的遇到需要看引擎内部调用栈的问题再回头补装这个组件就行Epic 的启动器支持后续单独添加。至于源码版引擎我的建议是除非你要改引擎源码否则不要碰。自己编译一次动辄一两个小时对机器的 CPU 和内存要求都高而且编译完之后目录结构和安装版不一样很多教程里的路径对不上新手很容易在这里耗掉一整周的热情。安装版足够覆盖 95% 的使用场景。还有一个容易被忽略的点离线安装包要留一份。引擎更新换代很快某个版本可能会在启动器里下架如果你手上的老项目锁死了那个版本到时候会非常被动。我的做法是把安装包和对应的项目工程放在同一个移动硬盘分区里写清楚版本号一年多没动过的就删掉。2.2 为什么改缓存目录是第一件该做的事**派生数据缓存Derived Data Cache简称 DDC**是 UE 最容易把 C 盘撑爆的东西没有之一。它的原理是引擎在导入贴图、编译着色器、生成材质预览的时候会把中间产物缓存起来下次再打开同一个项目就不用重新算。这些缓存默认放在C:\Users\你的用户名\AppData\Local\UnrealEngine\Common\DerivedDataCache这个目录的体积极其膨胀我见过一个中等规模项目跑一段时间后 DDC 突破一百 GB。再加上共享缓存目录通常在C:\ProgramData\Epic\UnrealEngine\Common\DerivedDataCache附近C 盘空间基本上是肉眼可见地掉。改缓存目录有两个收益很多人只知道第一个空间把缓存挪到容量大的盘上C 盘不再爆。速度把缓存放到一块读写快的 NVMe 固态上材质编辑器的预览编译、切换关卡时的着色器加载都会明显变快。我第一次改完之后同一个项目打开到可用状态的时间大概少了三分之一这不是玄学就是纯粹的磁盘随机读写差距。改法有几种我推荐优先级从高到低编辑器偏好设置 → 通用 → 全局 → 派生数据缓存分别设置本地和共享两个路径。这是最稳的方式因为它是按引擎版本生效的。命令行参数在启动快捷方式里加-DDCLocal或者直接给路径。适合需要临时切换、做对比测试的场景。环境变量UE-LocalDataCachePath和UE-SharedDataCachePath。适合一台机器上多个人共用、或者要统一团队配置的场景。注意改完必须重启编辑器和 Epic 启动器否则不生效。另外项目级的设置会覆盖全局设置如果你改了全局但还是慢去项目设置里翻一下是不是有项目级的缓存路径在起作用。2.3 项目内的目录约定与版本库配置缓存目录解决了接下来是项目本身的目录纪律。UE 的项目根目录里有几个文件夹是绝对不应该进版本库的Intermediate编译中间产物随时可以重建Saved日志、自动保存、崩溃报告、截图Binaries编译出来的可执行文件和 DLLDerivedDataCache项目级缓存.vs、*.slnIDE 生成物对应的.gitignore大概长这样Binaries/ DerivedDataCache/ Intermediate/ Saved/ .vs/ *.sln *.suo *.opensdf *.sdf真正需要进版本库的是Content资源、SourceC 代码、Config配置文件和.uproject本身。Config 一定要进库因为默认地图、默认 GameMode、输入映射这些全在里面丢了会导致项目打开后行为完全不对这类问题排查起来非常折磨人。我还额外在项目根目录放一个Docs文件夹专门放这个项目相关的笔记和 L1 速查卡。好处是笔记和代码永远在一起不会出现换了电脑笔记忘了拷的情况用 Git 同步也很自然。3. 蓝图与 C 的核心知识点卡片3.1 字符串与文本的区别FString、FText、FName这是我在 UE 里见过被问得最多的问题之一也是新手最容易踩坑的地方。三种类型名字看着像用途完全不同混用会导致中文乱码、本地化失效或者性能浪费。FString是运行时可变的字符串底层是宽字符TCHAR数组支持各种拼接、替换、格式化操作。它的定位是逻辑处理用的字符串拼路径、生成日志、解析配置文件、做字符串匹配都用它。代价是每次拼接和修改都可能产生新的内存分配所以别在每帧执行的代码里疯狂拼 FString。FText是面向玩家的文本核心特征是支持本地化。它内部存的是本地化表里的一个 Key而不是直接的字符串内容。这意味着两件事第一你不能用号拼接两个 FText那样会破坏 Key 结构编译就会报错正确的做法是用FText::Format配一个格式化模板第二所有会被玩家看到的文字——UI 按钮、任务描述、道具名称——都应该用 FText。FName是全局名称表里的一个索引不区分大小写比较的时候只比整数所以速度极快。它适合做键值、资源名、状态标记这类需要高频比较的字符串。代价是它的大小写不敏感如果你想区分Player和playerFName 做不到。类型可变大小写敏感本地化典型用途拼接方式FString是是否路径、日志、解析、Append、PrintfFText否需重建是是UI、任务文本、道具名FText::FormatFName否否否资源名、键值、标记不建议拼接互相转换有几个常用函数FText::FromString()把 FString 转成 FText注意这会丢失本地化能力只适合临时展示ToString()反过来FName(*SomeString)把 FString 转成 FName。这几个转换本身有开销所以别在 Tick 里反复转。实操心得判断该用哪个类型问自己一个问题——这段文字会被翻译成其他语言吗会用 FText不会但需要改用 FString改都不用改只做比较用 FName。这个判断规则我用了两年基本没错过。3.2 换行符从编辑器输入到代码解析的完整链路换行看起来是件微不足道的小事但它在 UE 里有至少四个不同的处理层面每一层都可能出问题。第一层是编辑器输入。在 Details 面板里给一个 FString 属性输入多行文本你按回车是提交不是换行。要真正输入换行得按ShiftEnter。这个操作我教过不下五个人每个人第一次都在这里卡住。第二层是代码里写字符串常量。直接写TEXT(第一行\n第二行)就行\n在 UE 的字符串常量里会被正确识别为换行符。第三层是外部数据读入。这是坑最多的地方。Windows 平台上的换行是\r\n回车 换行而 Linux 和 macOS 上是\n。如果你的文本数据是从 CSV、JSON 或者 Windows 记事本里导出来的里面很可能混着\r\n直接显示的时候你会发现每行末尾多一个看不见的字符或者排版莫名其妙多出一个空行。稳妥的做法是先统一替换再解析FString Raw TEXT(第一行\r\n第二行\n第三行\r\n); // 先统一换行符避免 Windows/Linux 混用导致的排版错乱 Raw.ReplaceInline(TEXT(\r\n), TEXT(\n)); Raw.ReplaceInline(TEXT(\r), TEXT(\n)); // 按行拆分成数组第二个参数 false 表示不保留空行 TArrayFString Lines; Raw.ParseIntoArrayLines(Lines, false); for (const FString Line : Lines) { UE_LOG(LogTemp, Log, TEXT(行内容: %s), *Line); }第四层是UMG 的显示。就算你的 FString 里有正确的\nText Block 也可能不换行——因为长句子的自动折行需要勾选Auto Wrap Text而\n是强制换行两者机制不一样。如果文字是在一个宽度受限的容器里两个都得配好否则会出现短句换了行但长句超出边界的奇怪现象。还有一个实际开发中经常遇到的场景用 DataTable 存对白文本。CSV 里的字段如果想包含换行需要用引号把整个字段包起来并且在引号内部用真实的换行。但不同版本的表格工具导出的格式不太一致我的建议是在 DataTable 里只存 Key把实际文本放到本地化表里这样换行、格式、本地化一次全解决不用每次跟 CSV 较劲。3.3 投掷物抛物线一份可以直接抄的参数记录投掷物这块我踩的坑最多因为它的参数之间存在耦合改一个另一个就崩。先讲原理再讲参数怎么记。抛体运动的水平射程公式是R v² · sin(2θ) / g其中 R 是水平射程v 是初速度θ 是发射仰角g 是重力加速度。UE 里默认的重力是-980 cm/s²单位是厘米不是米这是新手最常搞错的地方。如果你按米来算10 米要写成 1000。反过来如果你已经知道目标距离 R 和想要的仰角 θ求初速度就是v sqrt(R · g / sin(2θ))举个实测例子目标距离 1500 厘米15 米仰角 45 度那么 sin(90°) 1v sqrt(1500 × 980 / 1) ≈ 1212 cm/s。但实际在 UE 里用 ProjectileMovementComponent 的时候你会发现这个初速度还得再校正一点因为组件本身有一个 ProjectileGravityScale 会乘到重力上而且碰撞体有体积、空气阻力虽然默认是零但碰撞会损失速度。用项目里的实际参数时我的记录模板是这样一张表参数值说明InitialSpeed1500初速度单位 cm/sProjectileGravityScale1.0乘到世界重力上改这个等于改重力发射角度45蓝图里用 Velocity 向量控制目标距离约 1800实测落点比计算值略远bShouldBouncetrue撞击后是否弹跳Bounciness0.4弹性系数碰撞半径12影响贴合地面的表现手动拼速度向量的时候是拿一个方向向量旋转仰角再乘速度FVector Direction TargetLocation - StartLocation; Direction.Z 0.0f; Direction.Normalize(); const float Rad FMath::DegreesToRadians(45.0f); FVector LaunchVelocity Direction * FMath::Cos(Rad) * Speed; LaunchVelocity.Z FMath::Sin(Rad) * Speed; ProjectileComp-Velocity LaunchVelocity;但手动算角度有个问题玩家在游戏里是看着目标点扔他不知道角度是多少只想要一个漂亮的弧线。这时候用引擎自带的求解节点更省事FVector OutVelocity; const bool bSolved UGameplayStatics::SuggestProjectileVelocity_CustomArc( this, OutVelocity, StartLocation, TargetLocation, 0.0f, // OverrideGravityZ0 表示用世界默认 0.5f // ArcParam越大弧线越高 ); if (bSolved) { ProjectileComp-Velocity OutVelocity; }这个ArcParam的取值大概在 0.1 到 0.9 之间0.5 是中等弧度越接近 1 弧线越高、滞空越久。它的好处是直观——你调的是弧线多高而不是角度多少度对没有数学背景的策划和美术也友好。我在实际项目里基本都用这个只有需要精确复现某种固定弹道时才回去手算角度。注意用 CustomArc 的时候如果目标点比发射点高出太多可能会求解失败返回 false。一定要处理这个分支否则表现就是投掷物原地不动或者直接往天上飞。我的做法是求解失败时退化成直线速度或者给一个固定角度的兜底弹道。3.4 Size to Content 和 UMG 布局的记录方式Size to Content是 SizeBox 上的一个复选框勾上之后 Width Override 和 Height Override 会被忽略控件尺寸由子控件的 DesiredSize 决定。它解决的问题是内容长度不固定我又不想算尺寸。听起来很简单但实际用起来有三层坑。第一层是父容器决定一切如果父级是 Canvas PanelCanvas Panel 是不会主动调整子控件尺寸的你必须在锚点之外手动设置位置和尺寸或者在项目里改用它。如果父级是 Vertical Box 或 Horizontal BoxSize to Content 才真正能发挥作用。第二层是嵌套顺序。我用得最顺手的组合是Vertical Box → SizeBox(勾选 Size to Content) → Border(带 Padding) → Text Block(勾选 Auto Wrap Text)。这样文本变长时SizeBox 会先根据文本的 DesiredSize 撑开Border 负责内边距Vertical Box 负责上下排列各司其职。如果顺序反了尺寸计算会变得非常难预测。第三层是运行时动态改变内容之后的刷新。如果你在运行时用代码改了 Text Block 的文本布局不会立刻重算需要手动触发// 修改文本后强制重算布局 MyTextBlock-SetText(NewText); MySizeBox-InvalidateLayoutAndVolatility();不调用这一句的时候表现是内容变了但框还是原来的大小非常隐蔽。我在这个坑里待了整整半天最后是在引擎的 UMG 预计算流程里翻出来的。记录这类 UI 问题时我会强制自己写清楚四件事父容器是什么、锚点设在哪、有没有勾 Size to Content、有没有 Auto Wrap。这四项缺一项三个月后你就复现不出来。4. 渲染与性能那些最耗时间的问题4.1 平面反射倒影渐变的现象与参数记录平面反射Planar Reflection的原理其实很好理解把相机以反射平面为镜子翻到另一侧重新渲染一遍场景再把结果按屏幕投影贴回平面上。所以它不是免费的——每一个用平面反射的平面都会让场景被完整渲染一次Draw Call 直接翻倍。这也是为什么它基本只用在室内地面、镜面地板、水面这类少量高价值对象上。它的关键参数不少我按重要性排序记参数作用常用取值ScreenPercentage反射渲染的分辨率比例50-75越低越省NormalDistortionStrength法线扰动强度做波纹感0-0.5PrefilterRoughness预过滤粗糙度模糊反射0.1-0.6DistanceFromPlaneFadeStart开始淡出的距离按场景调DistanceFromPlaneFadeEnd完全淡出的距离按场景调倒影渐变这个效果本质上是离反射面越远的部分反射越弱。实现方式我试过三种第一种是直接用 DistanceFromPlaneFade 系列参数让反射随距离衰减最省事但衰减曲线不可控第二种是在材质里用 Depth Fade 节点做深度淡出把反射结果和底色混合第三种是叠一张渐变图当遮罩乘到反射亮度上可调性最强但需要美术配合。实测下来第二种和第三种组合用得最多Depth Fade 负责让反射在物体贴近地面时自然融入渐变遮罩负责控制整体的倒影淡出方向。如果只做第一种远处的反射会突然消失看起来像被切掉一样观感很奇怪。踩过的坑平面反射里出现的物件如果用了自定义深度或者半透明材质排序很容易出问题表现是反射里的物体闪烁或者位置错位。这种情况通常需要在材质里检查 Render Pass 设置或者在组件的排序优先级上手动干预。另外移动端上平面反射的开销真的很大我一般直接换成屏幕空间反射方案牺牲一点准确性换帧率。4.2 半透明景深为什么你的半透明物体不受景深影响这是 UE 渲染里最经典的问题之一。现象很明确场景里其他东西都糊了就半透明物体依旧锐利清晰像是浮在画面上。原因在于渲染顺序。半透明材质默认是在后处理之后才渲染的而景深Depth of Field属于后处理的一部分。渲染顺序决定了半透明物体根本看不到已经做好的景深效果自然不会被模糊。解决办法在材质设置里Translucency Pass选项有三个值。选项渲染时机效果代价Before DOF景深之前会被景深影响可能和粒子排序冲突After DOF景深之后默认不受景深影响无After Motion Blur运动模糊之后不受景深和动态模糊影响无所以想让半透明物体被景深影响把它改成Before DOF就对了。但别急着改因为改成 Before DOF 之后它会和粒子、其他半透明物体挤在同一个渲染阶段排序问题会立刻冒出来——表现是水面的反射突然出现在火焰前面或者角色背后的透明特效盖住了角色。如果需要在代码里动态控制可以拿到材质实例之后设置UMaterialInstanceDynamic* MID UMaterialInstanceDynamic::Create(BaseMaterial, this); MID-TranslucencyPass MTP_BeforeDOF; // 记得把 MID 应用到对应的 Mesh 上 MyMesh-SetMaterial(0, MID);注意TranslucencyPass属于材质覆盖项具体属性名和可用性以你所用引擎版本为准改之前先在编辑器里手动验证一遍效果再落到代码里别直接照抄。如果你只是想让半透明物体看起来有纵深感又不想动渲染顺序还有一个折中方案不用后处理景深改在材质里用深度相关的表达式手动做模糊采样。缺点是开销比引擎的景深更大而且边缘处理不如原生的干净。我在只处理一两个物件的时候用过这个办法数量一多就顶不住了。4.3 帧率低的排查从 stat unit 开始帧率问题最忌讳的就是凭感觉猜。UE 自带了一整套性能分析工具我把它整理成了一条排查路径基本能覆盖八成的情况。第一步永远是stat unit。这条命令会显示四个数字Frame、Game、Draw、GPU。判断方法很简单——哪个数字最接近 Frame那个就是瓶颈。现象瓶颈大致方向Game 最高CPU 逻辑线程蓝图 Tick、AI、物理、GCDraw 最高渲染线程Draw Call 太多、可见性剔除GPU 最高显卡像素着色、阴影、后处理、Lumen三个都低但 Frame 高同步等待线程同步、RHI 阻塞Game 线程高的时候我一般按这个顺序查先开stat game看具体是哪个部分耗时然后重点排查蓝图 Tick。最常见的三个元凶是在 Tick 里调用GetAllActorsOfClass、在 Tick 里做FindComponentByClass它内部是字符串/类查找非常贵、以及 Tick 里生成 Actor。前两个的正确做法是在BeginPlay里缓存一次引用后面直接用缓存的指针。Draw 线程高的时候用stat scenerendering看 Draw Call 数量然后开Shader Complexity视图模式看材质复杂度分布。有个经验值可以参考PC 上一个普通场景控制在两千到四千个 Draw Call 是比较舒服的超过八千基本就该动手合并了。合并的手段包括实例化静态网格ISM/HISM、合并材质、减少材质插槽数量、开启剔除。GPU 高的时候用ProfileGPU快捷键 CtrlShift会弹出一个按渲染 Pass 排序的耗时列表非常直观。常见的几个大户是Lumen 的全局光照和反射、虚拟阴影贴图、屏幕空间反射、粒子系统。Lumen 在有硬件光追的机器上可以切到硬件模式效果和性能曲线都不一样在低端机上直接关掉换成静态光照是最稳的选择。更深入的排查要用Unreal Insights。启动时加上-tracecpu,gpu,frame参数运行时就能抓一份完整的 trace然后在 Insights 里逐帧、逐线程看。它能回答stat系列回答不了的问题比如这帧的 Game 线程为什么卡了 40 毫秒。用stat startfile和stat stopfile也能导出一份统计文件适合不方便重启的情况。还有几个我踩过的、不太容易想到的坑Nanite 不是无脑开就快。它对大批量高面数模型的效果最好但对数量极少的低面数模型集群管理的开销反而可能让它比传统渲染慢。要实测。蓝图 nativization 在 UE5 已经移除了网上很多老教程还在教这个照做只会浪费时间。半透明材质越多越贵尤其是带折射和自定义深度的。能用不透明加遮罩解决的别用半透明。每帧修改材质参数Set Scalar Parameter也会累积开销如果参数值没变就别调。实操心得排查帧率问题一定要一次只改一个变量。我见过太多人同时关了 Lumen、降了分辨率、删了一半特效结果帧率上去了但完全不知道为什么上去了。下次再遇到同样的问题还是得从头来一遍。正确的做法是记录基线帧率改一项测一次记录数据这样最后你手上会有一份这个操作值多少帧的清单价值极高。5. 以策略游戏为例项目型资料该怎么组织5.1 策略类项目的系统模块索引策略游戏是我认为最能体现资料整理价值的项目类型因为它的系统多、耦合深、每个模块都有大量实现细节。我按模块建索引每个模块一个 Markdown 文件开头统一写三段这个模块解决什么问题、涉及哪些核心类、我在实现时放弃过哪些方案。摄像机系统是第一个坑。RTS 视角需要同时支持鼠标边缘滚动、拖拽平移、滚轮缩放、以及缩放时以鼠标位置为中心这个细节。最后那个特别容易出现缩放时视角漂移的问题因为你的缩放逻辑和位置补偿没对齐。我的做法是在缩放时同时计算鼠标投影到地面的世界坐标然后反推相机应该移动多少才能让那个点保持不动。参数上相机俯角一般固定在 50 到 60 度之间太低会导致远处单位被前景遮挡太高会失去立体感。选择系统分成三块单击选择、框选Marquee Selection、编队Control Group。框选的实现思路是把所有候选单位的包围盒投影到屏幕空间判断是否落在鼠标拖出的矩形内。这里有个性能陷阱单位多的时候不要每个都做投影先做一次视锥剔除只处理在屏幕内的。编队则要注意编队里单位死了怎么办我的做法是编队存的是弱引用每次使用前过滤一遍失效项。寻路是策略游戏的性能重灾区。基础方案是导航网格NavMesh配合 Detour 寻路关键是调好导航网格的 Agent Radius、Agent Height、Cell Size 三个参数——Cell Size 越小寻路越精确但生成时间和内存都涨得很快。单位数量上去之后还要开 RVO 避障在 CharacterMovement 上勾bUseRVOAvoidance或者用 Detour Crowd 组件否则一群单位会互相挤成一团。再往上如果单位数量到了几千个级别就得考虑 Mass Entity 框架把那部分逻辑从 Actor 体系里搬出去。指令系统我强烈建议一开始就用命令模式Command Pattern而不是直接调用函数。每个指令是一个对象带执行、取消、序列化三个能力。这样 Shift 排队指令、指令回放、网络同步都好做。代价是多一层抽象前期写起来慢一点但后期改动成本会低很多。迷雾Fog of War的实现思路是用一张 Render Target 记录可见性每个单位往上面画一个可见区域然后用材质把这个信息和场景混合。要注意的是已探索但当前不可见和完全没探索过是两个不同的状态需要两张或两个通道来记录。大量单位的渲染靠实例化静态网格ISM/HISM和动画共享。骨骼网格的开销远大于静态网格所以远距离的单位通常会用静态网格替代骨骼网格配合动画更新频率优化在 Skeletal Mesh 组件上开 Update Rate Optimization。5.2 从散笔记变成能检索的知识库上面这些模块如果每条都写成散笔记最后一定会变成另一个垃圾场。我的做法是给每个模块固定一个模板结构永远按这个顺序写模块目标一句话说清它解决什么问题。核心类清单涉及哪些类各自职责是什么。主流程从输入到输出的完整链路用文字描述不用图。关键参数表所有需要调的参数列成表格附上取值建议和理由。放弃的方案为什么没用另一个思路。已知问题目前还没解决的、或者有妥协的地方。第 5 项是最容易被跳过、但价值最高的一项。因为你写的每一行代码三个月后的自己都会问当时为什么不用另一种方式。如果不记你会在同一个决策上反复纠结甚至把已经否决过的方案再实现一遍。我的笔记里现在有十几条放弃的方案每次翻到都能省下半天。标签系统我也用但只用了五六个粗粒度标签#渲染#性能#UI#物理#数据#架构。标签太细等于没有标签粗粒度才能靠搜索快速收敛范围。6. 常见问题速查与避坑清单这一节是我自己笔记里最高频的部分直接整理成表格遇到问题先扫一遍。现象最可能的原因第一步该做什么打开项目卡在 Compiling Shaders 很久DDC 被清空或路径变了检查缓存路径确认盘符存在且可写改了缓存目录但新项目还是慢项目级设置覆盖了全局设置翻项目设置里的缓存配置UMG 里文本不换行换行符是\r\n或者没勾 Auto Wrap统一替换换行符检查 Wrap 选项FText 拼接编译报错FText 不支持改用FText::Format半透明物体不受景深影响渲染顺序在景深之后材质里改 Translucency Pass半透明物体排序闪烁排序优先级冲突调组件的 Translucency Sort Priority投掷物打不到目标重力被缩放了或单位算错检查 ProjectileGravityScale 和厘米单位SizeBox 尺寸不跟随内容父容器是 Canvas Panel换容器或手动设置尺寸运行时改文本后框没变大布局没重算调InvalidateLayoutAndVolatility帧率突然掉一半后处理或光照方案被改动stat unit定位瓶颈线程除了这张表还有几条我在长期项目里总结出来的、写进文档也不会有人看但确实有用的经验第一所有耗时超过半小时的调试过程当场记下来不要等。我试过先解决再记录的做法结果解决完之后那种终于搞定了的放松感会让你完全不想再回顾过程。而恰恰是过程里的弯路最有价值——因为下次你很可能走上同一条弯路。第二笔记里一定要写什么情况下这个结论不成立。比如半透明材质改成 Before DOF 会被景深影响这个结论在粒子系统上就不完全成立因为粒子的渲染路径和普通半透明网格不一样。如果不写清楚边界条件你会在错误的地方应用正确的结论然后怀疑结论错了。第三最小复现工程要定期清理但不要全删。我的做法是保留最近两年的更早的打包到一个归档目录里只在需要的时候解压。硬盘成本和重新调试的时间成本完全不成比例一个下午的调试时间远比几十 GB 空间值钱。7. 我在实际整理中形成的几个习惯最后说几个纯粹是个人经验的东西可能不适合所有人但对我帮助很大。我以前总想着先把资料整理好再开始学结果整理本身消耗掉了大量精力。后来我改成边学边整理且只整理已经用过的内容——没用过的、只是听说很厉害的不建卡。这条规则砍掉了我资料库里至少一半的噪音因为那些以后可能有用的东西百分之九十永远用不上。另一个习惯是每周花二十分钟回看一次 L1 速查卡。不是为了记住而是为了感受一下这些坑我踩过在真正遇到问题时能更快联想到答案在哪里。这二十分钟的投入产出比高得离谱。还有一个挺反直觉的经验不要追求资料库的完整性。我曾经花了两周时间想把 UE 的渲染管线整理成一份完整文档最后做出来一份自己都不看的四万字长文。现在我的笔记全是碎片化的、带强烈上下文的短条目反而真正被反复查阅。整理的目的从来不是覆盖所有知识而是在需要的时候能快速命中。想清楚这一点之后我在整理这件事上省下来的时间足够多做好几个功能了。