From 6186498778cc7ca2c56540fdec7b8d2b07cb9b8a Mon Sep 17 00:00:00 2001 From: BlueRose <378100977@qq.com> Date: Wed, 18 Jun 2025 15:04:37 +0800 Subject: [PATCH] vault backup: 2025-06-18 15:04:37 --- .../性能优化/UE5优化方法与实践笔记.md | 209 +++++++++++++++++- .../移动端/UE5移动端优化方法与实践笔记.md | 15 ++ 03-UnrealEngine/性能优化/移动端/Untitled.md | 9 - 3 files changed, 223 insertions(+), 10 deletions(-) create mode 100644 03-UnrealEngine/性能优化/移动端/UE5移动端优化方法与实践笔记.md delete mode 100644 03-UnrealEngine/性能优化/移动端/Untitled.md diff --git a/03-UnrealEngine/性能优化/UE5优化方法与实践笔记.md b/03-UnrealEngine/性能优化/UE5优化方法与实践笔记.md index 330594a..51c5af1 100644 --- a/03-UnrealEngine/性能优化/UE5优化方法与实践笔记.md +++ b/03-UnrealEngine/性能优化/UE5优化方法与实践笔记.md @@ -276,4 +276,211 @@ UE5使用DLSS时需要关闭TAA,并且调整[[ScreenPercentage与描边宽度 - More Bools! - bRenderAsStatic :UE5.2不存在该选项。 - bPauseAnims:该选项位于SkeletalMeshComponent。 - - bNoSkeletonUpdate:该选项位于SkeletalMeshComponent。 \ No newline at end of file + - bNoSkeletonUpdate:该选项位于SkeletalMeshComponent。 + +# DrawCall优化相关 +使用**Stat DrawCount** 可以参看当前视角所有Pass所有DrawCall。 + +使用**Stat SceneRendering** 可以查看Mesh Draw Call。 + +# Shadow优化 +原文:https://zhuanlan.zhihu.com/p/644620609 +## 阴影 +阴影主要聊一下平行光的两个解决方案,一个传统的[CSM](https://zhida.zhihu.com/search?content_id=231379699&content_type=Article&match_order=1&q=CSM&zhida_source=entity),一个是ue5配合nanite的[VSM](https://zhida.zhihu.com/search?content_id=231379699&content_type=Article&match_order=1&q=VSM&zhida_source=entity).传统的CSM效果最好,没有噪点,也没有BUG,但是走了Nanite的话,CSM跟nanite配合是水士不服。UE5主推的VSM,性能最好,但是bug多,有噪点,但是又没办法跟距离场配合,开启了VSM,平行光的阴影只有VSM这一种,真是又爱又恨。 + +### csm +CSM的实行网上教程很多,这里主要聊优化手段。 +- CSM缓存 +可以通过r.Shadow.CSMCaching修改为1,开启csm缓存.它会为静态和动态的对像分别启用一张深度图,动态的深度图每帧都会重绘,但是可以通过r.Shadow.CacheWPOPrimitives调整,让WPO的也强制缓存。当两帧平行光没有变化,而且两帧的CSM重叠超过一个阈值的时候,CSM会复用上一帧的深度图,这个阈值通过r.Shadow.CSMScrollingOverlapAreaThrottle调整,默认是0.75。这个CSM缓存在低分辨率下的时候也个好优化,对于高分辨率,深度图失效的时候会重现申请,申请这个RT是个不少的消耗,这一点要注意。 + +- CSM层遮挡剔除 +CSM有好多层,如果前面有个建筑物很高,完全档住人你的视线,这里CSM,远处的层级照样绘制深度,这个是没有必要的,可以通过遮挡剔除优化掉,UE也做了这个优化。过能r.Shadow.OcclusionCullCascadedShadowMaps修改,让不在视野范围的深度图不参与计算,这个是个不错的优化,最好开启。 + +- 调整屏幕占比factor +对于一些特别远的,屏幕占比很低的物体,没必要去生成深度,可以通过修改r.Shadow.RadiusThreshold生成深度图的对像的半径阈值。 + +- 强制使用LOD +可以通过r.ForceLODShadow调用生成阴影深度的LOD,这个是个大优化。 + +- 调整分辨率 +这个优化是最好的,直接把分辨率降低,消耗直接变低。r.Shadow.MaxCSMResolution可以通过此参数调整csm每层的分辨率。 + +- 逐帧更新 +因为csm有很多层,对于远处的层,没必要每帧都更新,可以在csm缓存的代码里,修改一下,就可以做到远处的层级逐帧更新,这个优化,可以把CSM的性能提高了好多。 + +- 代理阴影 +对于非nanite的网格体,有强制使用LOD,可以降低深度图对像的面数,但是对于nanite,前面的手段是不生效的。对于nanite来说,走的是自已的[raster](https://zhida.zhihu.com/search?content_id=231379699&content_type=Article&match_order=1&q=raster&zhida_source=entity)。但是很多时候nanite光栅化出来的面数非常巨大,引起nanite切换lod失效的因素非常多。所以对于那些远处,又或者自投影细节比较少的网格体,可以使用代理nanite阴影去解决。修改引擎支持proxyshadow component,只设置影响深度pass,其它pass都不绘制,可以解决nanite在csm情况下LOD失效的时候减面优化性能。 + +上面的手段,基本都是对于非nanite的有效,对于nanite的,上面的优化手段基本都是失效的,nanite的网格全是gpu driver的,有自已的渲染管线。 + +### vsm +VSM的原理就是一张大VT,不同clipmap范围的VT页分辨率不一样,同时动静分离,在平行光不变的情况下,静态页面复用,只重绘动态的页面,同时对于动态的页面缓存,非nanite的网格体也可以缓存,可以通过r.Shadow.Virtual.Cache.MaxMaterialPositionInvalidationRange调整数值,让离自已一定范围内的非nanite才失效,超过强行缓存。对于平行光不停在变情况的情况下,所有页面都在失效,这时可以关闭缓存(r.shadow.vsm.cache),反而可以提高一点性能,节省一些显存,因为不分动静页,也不会分析哪些而页面失效。 + +目前VSM的问题比较多,主要集中在两个方面,bug多和噪点问题,bug比如,页面分析出错,应该失效的页面不失效,大范围WPO导致超出cluster bound box,导致深度图被clamp在一个范围内,同一个物体的深度在不同clipmap下的页面不一至 ,导致一些奇奇怪怪的阴影错乱问题, 噪点问题是算法决定了,smrt,判断是否是软阴影的一个算法,当一个像素发送射线过多,会导致性能不行,过低,噪点严重。总体来说,VSM,还不能完全线上使用。 + +VSM配合nanite使用,性能是非常好的,下面讲一下VSM的一些优化手段,主要是降分辨率。 + +- clipmap范围与页面密度 +可以通过调用r.Shadow.Virtual.Clipmap.FistLevel和LastLevel来调clipmap的覆盖范围,在不同的clipmap有同的页面覆盖面积。这里不仅可以优化性能,也可以优化显存。 + +- 分辨率bias +在clipmap范围不变的情况下,可以通过调整每个页面的覆盖范围,通过调整r.Shadow.Virtual.ResolutionLodBiasDirectional来修改平行光的页面覆盖面积以达到降分辨率的处理 + +- 非nanite物体wpo强制缓存 +调整r.Shadow.Virtual.Cache.MaxMaterialPositionInvalidationRange数值,让在数值范围内的WPO强制使用缓存。 + +### 距离场阴影 +距离场阴影的原理是,把屏幕切tile,在cs里,找到每个tile对应有可能overlap的距离场,然后每个tile每个像素追踪距离场,就可以知道像素是否在阴影下。距离场阴影性能非常好。对于远处的物体阴影 ,都建议开距离场阴影。但是,在VSM开启的情况下,Nanite物体距离场是失效的。 + +对于点光的阴影,可以通过在远距离时使用距离场阴影,近距离影时使用shadowmap。 + +这里提示一点,在室内或者完全不受平行光的环境下,可以把平行光的阴影关掉,用距离场去代替。 + +### 接触阴影 +接触阴影主要是屏幕空间下的通过hzb追踪得来的阴影,他会有效果表现下比较差,但是对于植被这种,特别适合,当场景大量存在存被的情况下,可以开启接触阴影。 + +### 点光源 +对于点光在GPU端,分两种情况,直接阴影和间接阴影。有三种阴影选择,深度图,接触阴影,距离场,接触阴影效果不好,深度图精度最高,支持动态物体,但是很影响性能,距离场性能最好,但是不支持动态物体。对于远一点的,可以用距离场代替,随着距离变近,切换到shadowmap,把光源交由逻辑层管理。 + +如果一个光源间接光照强度大于0,此光源就会在[lumen scene](https://zhida.zhihu.com/search?content_id=231379699&content_type=Article&match_order=1&q=lumen+scene&zhida_source=entity)生效,在lumen scene里不仅要计算光照,也要计算阴影,包括离屏阴影,性能消耗不低,无论使用shadowmap还是距离场,这里交由脚本层管理,过远的把间接光照强度调成0,不参与lumen scene. + +## [RVT](https://zhida.zhihu.com/search?content_id=231379699&content_type=Article&match_order=1&q=RVT&zhida_source=entity) +RVT的使用教程知乎非常多,这里聊一下性能优化点。对于贴图混合层特别多的时候,用RVT可以优化非常大的性能,特别是地形,但是RVT有时候也会突然消耗非常高,可达3MS以上,下面各个聊。 + +### produce与upload +当VT不存在,或者MIP级别不匹配的时候,引擎会从磁盘(svt)或者通过drawcall(rvt)生成对应的tile,这个过程叫produce,当生成后,就会upload到gpu中,更新indirect table和vt图集,这个过种叫upload. + +### produce +svt的produce不影响性能,主要影响性的是地形的rvt的produce,因为地形的图层太多了,这里会通过调用地形的材质drawcall生成对应的vt tile.这里性能消耗是不低的,可以通过r.VT.MaxTilesProducedPerFrame调整数量,注意,这个参数是包括svt的tile数量。 + +### upload +一般upload不会产生GPU的消耗,除非你的upload数量非常高。可以通过r.VT.MaxUploadsPerFrame调整每帧的upload数量,编辑下通过r.VT.MaxUploadsPerFrameInEditor调整。 + +### VT池问题 +当VT池不足的时候,vt池会不停的切换mip以降显存,这里GPU的VT消耗就会起来。可以通过命令r.VT.Residency.Show查看哪些VT池不足,也可以通过r.VT.Residency.Notify,当对应的池不足切mip的时候,屏幕下会有打印warning,找到对应的池,在配置文件里增大显存。 + +### 地形 +地形用RVT去减少采样是个非常大的优化,另外RVT支持离线烘倍,可以把低的mip离线烘倍,减少切mip的时候的draw call发生以优化性能。通过RVT Volumn下的虚拟纹理构建,把低的MIP烘倍出来。 + +## Nanite +nanite是UE5最稳定,性能最好的新技术,对于实现原理,没有想像中这么复杂,可以去看一下知乎大佬丛越系列的文章,讲的非常详细,这里聊一下nanite遇到的性能问题。 + +### WPO +WPO非常影响性能,当cluster剔除后,光栅化后出来的面数也不低,全开WPO,会让vibility buffer生成性能翻倍,这里可以使用世界位置偏移禁用距离调整,超过距离后WPO禁用 + +### Mask +当有mask材质的时候,没办法通过HZB做剔除,只能先光栅化出来才能通过alphatest来决定去流,overdraw非常严重,对于nanite的材质,最好禁用mask材质。使用mask材质性能非常低,之前有测试过,有mask性能直接减半。 + +### LOD减面失效问题 +nanite的减面是要依赖平滑法线组去决定三角面是否能合并,如果一个模形导出的时候没有平滑法线组,UE会有warning,这个要特别注意,如果没有平滑法线组,面数非常爆裂。 + +### Drawcall问题 +nanite的bass pass是通过在屏幕空间切tile,每个tile有要用到drawcall的材质,CPU端是不知道此时GPU端哪些材质是否draw,所以nanite的draw call是在CPU端,把加载进来的所有材质都发起drawcall,每个drawcall是一个quad,没有在屏幕的时候在vs阶段就culling掉.正常来说,一个culling掉的drawcall是基本不耗时的,但是在一些老显卡(20系),一个culling掉的drawcall,也会有小耗时,如果材质多的话,这些culling掉的drawcall是个不小的消耗。 + +### 破面问题 +引起破面的问题主要有下面几个因素,但是几个因素引起的表现不太一样,下面一个一个聊。 + +### 实例数 +nanite在raster的时候会限制BVH node节点数量,可以通过r.Nanite.MaxNodes去调整,当实例数超过上限的时候,场景每帧会随机掉面。 + +### cluster数 +这里有两个类型cluster,一个是candicate cluster,一个是visiable cluster,分别通过r.Nanite.MaxCandidateClusters和r.Nanite.MaxVisibleClusters,当场景cluster数量足的时候,场景会随机掉失cluster,整个画面在闪烁。 + +对于实例数和cluster数的统计,可以通过nanitestats去看到当前的数据,可能数据非常接近上限的时候,就要调整,这里要注意一点,当使用VSM的时候,如果在VSM的view这些数量也超过了,会导致深度生成每帧都不一样,阴影会错乱. + +### nanite流送池显存不足 +nanite是通过每帧的feedback去让CPU发起流送的,当流送池显存不够的时候,就是流送低的cluster tree,这个时候整个场景的面数非常低,而且会破面。 + +### cluster id上限 +这个没找到原因,当上述所有条件都足够的情况下,仍然会出现随机破面,画面闪烁的问题。当场景存在大量的nanite,而且每个nanite实例都是分离的,最后退化一个cluster的时候,这个cluster仍然很多,这个时候,也会随机破面,目前怀疑是跟 cluster id上限的问题。主要出现在植被非常多的时候。 + +## Lumen +UE5默认lumen是把效果,质量都是拉满的,如果默认使用lumen的参数,性能很炸。对于lumen,反而bug比较少,主要问题是在集中在性能问题。lumen对场景的效果的提升确实有的,但是很多时候,质量拉满和质量很低的情况下,画面其实看不出有多少区别,所以,在我看来,lumen要用,但不须要很高的质量,基本于这个观点出现,lumen就有很多地方可以优化,如果当某个地方须要很高lumen质量的时候,可以在拉一个新的post process volume,提高lumen的质量。lumen整体分成三个部分,lighting,probe gather,反射,下面集中围绕这三个聊一下优能优化的点。另外,想了解lumen的实现,可以参考丛越大佬的文章,写得非常详细。 + +### Lighting速度 +lumen首先通地在lumen的direct ligting,再加上radiosity的得到每一个patch的lighting,最终combine lighting成indirect lighting.在接下的阶段final gather中,放入probe去trace,得到final lighting.这里有两个参数比较影响性能。 + +- direct lighting速度 +可以通过修改r.LumenScene.DirectLighting.UpdateFactor参数和LumenSceneLightingUpdateSpeed两个参数控制更新速度,前者是分母,后者是分子,这两个参数共同决定了当前帧分配更新图集大小。此图集通过PriorityHistogram中收集优先级的surface cache的tile放入到更新图集,从而达到分帧更新。 + +- final gather速度 +总体流程跟上面类似,通过r.Lumen.ScreenProbeGather.RadianceCache.NumProbesToTraceBudget和LumenFinalGatherLightingUpdateSpeed参数总同决定了final gather阶段最大的trace probe数量,在SelectMaxPriorityBucketCS中选择优化级大的,而且小于上述两个参数共同决定的最大上限probe数去trace. + +### 追踪距离 +可以通过r.Lumen.TraceDistanceScale和LumenMaxTraceDistance去决定在lumen下距离场的最大追踪距离。这两个参数是影响整个lumen须要距离场cone trace追踪的所有pass,包括final gather的radian cache trace,radiosity的trace,reflect的trace,减少追踪距离,可以优化性能,但是会带来一些不想要的后果,比如反射不到,lumen scene阴影漏光(导致场景有些地方会有从亮到暗的过程),泄露天光等。这里可以在不同区域拉不同的pp盒子,在一些野外,把追踪距离设置小一点提高性能,在一些封闭的地方或者须要反射的地方,可以把追踪距离设置大点。 + +### 离屏阴影 +lumen scene的lighting不仅要算colour,也要计算阴影,它不仅是当前屏幕的,是包括整个surface cache的,对于离屏阴影,UE默认使用mesh object sdf去追踪,如果场景存在大量物体,每个物体都有[mesh sdf](https://zhida.zhihu.com/search?content_id=231379699&content_type=Article&match_order=1&q=mesh+sdf&zhida_source=entity),这样子每个surface cache tile对应的可能对交的mesh sdf非常多,每个一像素对各个mesh sdf追踪是个很大的性能问题,而且对于离屏的阴影,大部分是不须要mesh sdf去追踪,野外大场景,如果一个mesh太小,就算lumen scene 露光也看不出来,对于室内,存在小的sdf漏光找美术去调整就好。 + +能过r.LumenScene.DirectLighting.OffscreenShadowing.TraceMeshSDFs设置为0,关闭离屏的mesh sdf trace,使用global sdf去trace. + +### Mesh SDF +mesh sdf是lumen的核心,就我看来,目前lumen的消耗有80%来源于mesh sdf,用到mesh sdf的地方非常多。可以通过LumenSceneDetail和r.Lumen.DiffuseIndirect.MeshSDF.RadiusThreshold共同控制,让物体包围球的半径大于上述两个决定的数值的时候,才参与mesh sdf的软追踪。这个优化非常大,特别场景存在大量的小物体的时候,比如植被,这些小物体对于lumen scene的贡献非常低,当然,除了反射。为了解决反射这种情况,我们并没有使用上面的参数控制小物体距离场生效与否,我们直接把小物体的距离场全都默认关闭,这样子,对于须要反射的地方,小物体手动开启距离场。 + +另外,调整LumenSceneDetail不仅会影响mesh sdf的culling,也会导致mesh card的丢失,这个参数会引够mesh card小于某个分辨率的时候也会culling掉,在surceface cache视图可以看到很多黄色图块(黄色的代表culling掉,紫色代表没有surface cache),这会引起光照的异常(黑影)。 + +### TraceProbe数量 +在final gather阶段是非常耗时的,最直观的影响因素就是trace射线的数量,它是由八面体probe的密度,每个probe trace的射线数量共同决定。probe的密度通过r.Lumen.ScreenProbeGather.DownsampleFactor和LumenFinalGatherQuality共同决定,八面体,每个面的trace线射数量由r.Lumen.ScreenProbeGather.TracingOctahedronResolution和LumenFinalGatherQuality共同决定。这个参数数值,可以在不同的情况调整不同的数值,在野外调到最低,在室内或者封闭的地方相应调高。 + +### 反射分辨率 +这个非常影响性能,这个目前没找到优化方案,最快的解决方式是降低反射buffer的分辨率,须要高精度的反射,比如达到镜面反射的情况,把pp盒的lumen反射质量调高,其它情况默认调到中档质量,低质量是没有反射。 + +lumen默认管方都是质量拉满的,可以调优的地方非常多,另外,lumen非常吃显存,对于显存部分的,有机会在显存篇幅里介绍。 + +### 异步Lumen +lumen在5.1后支持了异步lumen,这个是依赖GPU Async Compute,这个开启后在我们项目Lumen能节省1~2ms的消耗。 + +- 异步Light Probe Gather +首先要支持GSupportsEfficientAsyncCompute,AMD默认支持,N卡默认关闭,可以通过命名行ForceAsyncCompute强制打开。 + + + +另外,通过r.LumenScene.DirectLighting.ReuseShadowMaps关闭lumen scene下的复用阴影的shadow map,使用距离场阴影代替,注意,这会导致动态骨骼在lumen scene没有阴影,而且距离场阴影是很难跟shadowmap的阴影一致的,这会导致两种方式下final lighting会不一样。r.Lumen.DiffuseIndirect.AsyncCompute打开支持异步light probe gather,通过以上三个,异步Light Probe Gather就支持了。 + +- 异步Reflect +在r.LumenScene.DirectLighting.ReuseShadowMaps关闭下,异步反射可以通过r.Lumen.Reflections.AsyncCompute打开了。 + +- 异步Lighting +可以通过r.LumenScene.Lighting.AsyncCompute打开异步lighting. + +通过上面三个把异步lumen全部打开的情况下,在已经经过极致优化的lumen下,还可以优化到1到2MS,把lumen在GPU的耗时压得很低,而且不失效果。 + +## 植被问题 +植被有两个方向可以走,nanite与普通植被,各有利弊。 + +### nanite植被 +当植被开启nanite后,性能可以提高一倍以上,就算面数非常高,不可视的面都在nanite culling介段剔除掉。nanite植被有两个问题非常影响性能,wpo和mask,wpo前面nanite有提到,可以超过一定的距离禁用。对于mask材质,建议走实体模型。另外,当植被数量到达一定程度,nanite cluster会随机丢失造成画面闪烁。 + +### 普通植被 +普通植被最快,最有效的优化方式是做好LOD,减少culling distance.除此之外,还有两个因素对性能也有一定的影响。 + +- foliage actor的范围 +foliage actor的默认tile的大小是256,如果一个tile下有大量的植被,而且植被密度非常浓密的时候,这里不仅会引起分区流送引起cluster tree构建的卡顿,也会导致gpu下prepass和basspass消耗过高,因为默认的剔除盒子太大,导致prepass和basspass存在大量的vs的overdraw. + +- cluster tree遮挡剔除盒子大小 +cluste tree的剔除盒大小,决定了这一块instance是否绘制,过大的盒子,会引起prepass和basspass的vs阶段的overdraw,过小的盒子,导致存在大量的遮挡剔除查询导致render线程耗时过高,而且也会产生过多的drawcall。引擎对于cluster tree的控制参数都是全局的,有一些component适用,也一些则不合适。过密的component须要提高盒子的粒度,过于稀疏而且面数不高的,可以减少盒子数。因为,如果植被特别影响性能的时候,可以修改引擎支持让这些参数跟着component走。引起cluster tree盒子的因素有点多,这里主要聊三个。 + +- foliage.MaxOcclusionQueriesPerComponent +控制每个component的最多盒子数 + +- foliage.MinOcclusionQueriesPerComponent +控制每个component的最少盒子数 + +- foliage.MinInstancesPerOcclusionQuery +控制每个盒子最小包含的实例数 + +如果这个盒子粒度控制好,在植被比较多的情况下,可以在prepass和basspass省下2MS的预算。 + +## SingleLayerWater +如果水材质的效果不是用面表达的,是用法线贴图去做的话,可以把材质的mesh换成一个quad,高面的plane,在singlelayerwater里非常耗时。 + +## 直接光照 +### cluster deffer lighting +推荐知乎大佬(张亚坤:多光源渲染的版本答案:Cluster Shading)的文章,对于cluster deferred lighting有个介绍,先简单说一下cluster deferred流程。在gather light介段,把视锥体切豆腐,在cs中把光源注入到格子中,然后在cluster deferring shading的发起一个quad的drawcall,每个像素找到对应的grid,从grid中找到对应的light,叠加shading.cluster shading性能肯定是非常好的,优化地方不多,只与采样的buffer大小有关。 + +UE5默认是关闭cluster deffered shading的,可以通过r.UseClusteredDeferredShading打开。 + +引起不能cluster shading的原因有很多,如产生阴影,有light function,使用light channel,平行光,rect光等。在非cluster shading与unbatch light之间,还有一些light,主要是非shadow,非light function的,主要是rect等,每一个发起一个drawcall,这里消耗不低,能减少就减少一下,把生效距离设置短一点。 + +### unbatch light +对于unbatch light,主要是lumen scene light和正常的直接光照light,这里就不说了,光照lighting,shadow mask生成,有距离场阴影的也在这里追踪,建议就是交由逻辑层管理,根据不同策略动态开关。 diff --git a/03-UnrealEngine/性能优化/移动端/UE5移动端优化方法与实践笔记.md b/03-UnrealEngine/性能优化/移动端/UE5移动端优化方法与实践笔记.md new file mode 100644 index 0000000..9ef7c53 --- /dev/null +++ b/03-UnrealEngine/性能优化/移动端/UE5移动端优化方法与实践笔记.md @@ -0,0 +1,15 @@ +--- +title: Untitled +date: 2025-06-09 18:05:03 +excerpt: +tags: +rating: ⭐ +--- +# 前言 +- [移动游戏的性能优化 | 材质优化篇 - 腾讯游戏学堂的文章](https://zhuanlan.zhihu.com/p/688098852) +- [UE4移动端性能分析](https://zhuanlan.zhihu.com/p/1034898589) + +# 合批 +## UE4移动端合批 +- [UE4 4.23 移动端渲染的Dynamic Instancing分析(上)](https://zhuanlan.zhihu.com/p/99789976) +- [UE4 4.23 移动端渲染的Dynamic Instancing分析(下)](https://zhuanlan.zhihu.com/p/100224369) \ No newline at end of file diff --git a/03-UnrealEngine/性能优化/移动端/Untitled.md b/03-UnrealEngine/性能优化/移动端/Untitled.md deleted file mode 100644 index dd5738a..0000000 --- a/03-UnrealEngine/性能优化/移动端/Untitled.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Untitled -date: 2025-06-09 18:05:03 -excerpt: -tags: -rating: ⭐ ---- -# 前言 -- [移动游戏的性能优化 | 材质优化篇 - 腾讯游戏学堂的文章](https://zhuanlan.zhihu.com/p/688098852) \ No newline at end of file