引擎迁移这件事在游戏行业里从来不只是一个技术选项它更像是一场被项目进程狠狠逼到墙角后的背水一战。《最终幻想15》从最初形态的《Versus XIII》一路走到正式发售背后最关键的转折点就是把整个项目从 Ebony 引擎整体迁往 Luminous 引擎。这篇研究报告想要做的事就是围绕那次引擎迁移展开重点拆解迁移前后大气系统与光源环境的实现差异分析 Luminous 为开放世界场景重写了哪些底层设施并尝试还原资产管线迁移过程中那些常规文档里不会写的坑。无论你是在评估自研引擎是否要迁移还是在研究大世界场景的光照调优这篇文章应该都能给你一份可以直接参考的思路。很多人会问为什么不早换引擎如果换为什么不干脆用商业引擎这个问题放到当时的 Square Enix 语境里没有标准答案但正是这种没有标准答案的处境让这次迁移本身变得非常有研究价值。下面这些内容我不会照搬官方宣传口径而是以图形开发者的视角把那次迁移的动机、技术拆解、资产再造过程和最终性能表现串在一起讲一遍希望对同样在折腾引擎的同行有点启发。1. 为什么要换掉 Ebony一次发生在开发链中段的生死决策1.1 从 V13 到 FF15项目定位升级直接击穿了 Ebony 的能力上限时间线倒回 2006 年《最终幻想 Versus XIII》作为 Fabula Nova Crystallis 系列的一块拼图对外公布导演是野村哲也。当时它的目标平台是 PS3技术底子是 Square Enix 内部为这个项目单独搭建、后来被坊间称为 Ebony 的引擎。这里要先说清楚一个概念Ebony 不是那种有完善文档、成熟生态的商业授权引擎它更像是一个围绕《Versus XIII》早期玩法和线性关卡设计的定制渲染器服务的是“一段经过精心编排的动作演出”这个目标。从我看到的有限公开资料和当年访谈中透露出的碎片来拼图Versus XIII 初期的场景规模并没有做到后来开放世界的量级实景环境复杂度、日夜循环、天气变化这些系统都没有被提到太高的优先级。换句话说Ebony 最初的任务是“在一个受控的线性流程里把角色的动作和演出做到尽可能精致”。这个目标本身没有错问题在于它撑不过项目的下一次升级。2012 年前后是真正的分水岭。项目正式更名为《FINAL FANTASY XV》目标平台从 PS3 迁移到 PS4 与 Xbox One游戏形态从一个偏线性的动作 RPG 升级为开放世界。就这么一改Ebony 的短板几乎全被戳中场景数据量不再是一两个关卡而是一整块无缝大陆光照不再是一组手动摆好的灯光而是要应对日光、月光、人工光随时切换的动态环境性能预算虽然从 PS3 换到了 PS4但与此同时期望画质也抬上了一个台阶。Ebony 从来没见过这种阵容“用旧引擎跑新项目”这条路基本被堵死了。1.2 Ebony 在渲染能力和工具链上的真实短板关于 Ebony 本身公开的技术文档少得可怜但从“最终成品里几乎没有保留 Ebony 痕迹”这个结果去倒推还是能大致摸到它的边界。首先渲染管线上它大概率还是老一代的前向光照思路对多光源场景非常不友好。开放世界场景里任意位置都可能出现十几盏灯街道灯火、车辆头灯、魔法特效叠加在一起前向渲染在光源数量和光照计算精度上很难维持住平衡。其次是工具链。Ebony 的年代对应的是 PS3 世代美术的日常工作流要打通建模软件、关卡编辑器、资源打包工具最后才能看到效果。这个链路越到后期越不适合开放世界的大规模迭代策划想在河边加一百棵树美术想调整一张 PBR 贴图的粗糙度这些改动在旧引擎里都可能触发很长的资源烘焙时间。我在以前的团队里经历过类似的问题引擎工具链一旦跟不上团队的效率不是线性下降而是雪崩式下降。还有一点是光照数据的组织方式。旧世代游戏普遍重度依赖预计算的烘焙光一个场景的光照效果在离线状态就算好了运行时只是把结果贴上去。Ebony 也不例外。但 FF15 需要的是能随昼夜变化、随天气转换而实时调整的光照不然太阳落山后烘焙光不会自动变暗雨天的环境光也不会自动变成阴沉灰蓝色。这不是给灯光调几个参数就能糊弄过去的而是要从光照架构上换一套思路。1.3 换引擎的沉没成本为什么 SE 愿意吞下这笔账换引擎最难的不是技术而是说服团队和投资人接受已经付出的沉没成本。当时的 Versus XIII 已经做了好几年角色设定、武器、菜单 UI、一部分过场动画、音乐甚至一些关卡模块都已经成型。这些东西全部要在新引擎里重新验证不兼容的部分还得重做。但 Square Enix 最终仍然做了这个决定理由其实非常理性。站在 2012 年的节点往回看PS3 世代已经接近尾声PS4 世代在算力、内存带宽、渲染特性上的变化几乎是代差级的。如果继续抱着 Ebony 做下去FF15 大概率只能在沿用旧技术的框架里小幅提升画质撑不起“次世代最终幻想”的名号。同时从公司长期战略看SE 也需要一个能与时代同步的下一代自研引擎来支撑接下来几年的产品线。与其把资源继续投入一个上限已经封死的 Ebony不如壮士断腕把筹码全部押到 Luminous 上。我个人的判断是这个决策放在当时的战略层面是成立的尽管执行过程无比痛苦。2. Luminous 引擎的底层重构为开放世界重写了哪几块核心2.1 Luminous 的定位不是大而全的商业引擎而是 FF15 的定制底座Luminous 这个名字来自拉丁语的“光线”SE 对它的期待明显不只是“能跑游戏的引擎”而是“能让画面发光”的渲染平台。2014 年公开的实时技术 Demo《Agnis Philosophy》让很多人第一次正面感受到 Luminous 的能力细腻的皮肤质感、真实摆动的布料、复杂的金属与环境反射、带着体积感的雾气。这个 Demo 的完成度放在当时相当惊人事后看它其实就是在为 FF15 的实机渲染定调。但要注意Luminous 不是 Unreal 那种开箱即用、覆盖所有游戏类型的通用引擎。它生来就是围绕 FF15 这种特定类型的动作 RPG 设计的技术重心放在角色表现、开放世界地形流送、动态光照这三条主线上。这种“自研引擎服务单一大项目”的模式在大型工作室里很常见优点是迭代节奏完全由项目需求驱动缺点是引擎的通用性差项目一旦转型引擎也要跟着大改。FF15 结束后 Luminous 引擎后续没有大规模铺开也印证了这个定位的局限性。2.2 渲染管线从旧式光照到延迟渲染为多光源环境铺路FF15 的地图是那种随时随地会冒出一片城镇、一片战斗区域的世界。城镇里有霓虹灯、路灯、车辆灯光战斗中有武器光效、魔法燃烧的粒子光。面对这种密度和类型完全不可控的动态光源延迟渲染几乎是那个时代的唯一合理选择。延迟渲染先把位置、法线、颜色、粗糙度、金属度这些几何信息写进 GBuffer再在光照阶段用几张全屏 Pass 集中处理所有光源的贡献这样场景中光源数量和复杂程度对性能的冲击会远小于前向渲染逐物体加灯的模式。当然延迟渲染也不是没有代价。GBuffer 的内存占用和带宽压力非常大对 PS4 并不宽裕的显存来说尤其紧张。我看到 FF15 实机画面时的第一直觉是开发团队在 GBuffer 的分配上一定做了非常精细的取舍因为画面里反射和粗糙度的区分度很高材质通道的精度保住了。而这种“保住精度”的背后往往就是一个项目组反复压性能预算压出来的结果。延迟渲染的 Artifacts 大家也都清楚MSAA 不友好、透明物体处理和采样复杂度高Luminous 里应该有专门针对角色、特效等透明物体做前向路径的设计只是官方没有把细节全部公开。2.3 材质系统与 PBR告别旧式高光模型的第一次资产清洗在 PBR基于物理的渲染成为行业主流之前游戏材质大多跑的是 Phong / Blinn-Phong 那套“给一个高光颜色和高光强度”的模型。这种模型非常依赖美术的手感材质接近真实还是像塑料完全靠调参经验。Luminous 选择了用 metalness/roughness 工作流来描述材质一张金属度贴图告诉引擎这块地方是金属还是非金属一张粗糙度贴图告诉引擎表面有多光滑然后漫反射和高光反射都按物理模型计算。这套工作流在光的响应上更准确但代价是旧资产必须做一轮大规模的重新转换。转换带来的画面提升非常直观金属材质在月光下的反射不再是一层笼统的白光而是带着环境色的真实倒影布料和皮肤在不同光源角度下会呈现不同的微表面高光。FF15 里诺克提斯的皮衣、跑车漆面、机械结构的金属质感在 Luminous 里的观感都比传统高光模型高出一大截。PBR 不只是画面变好看了更关键的是它让美术在调整材质时有了更接近物理世界的直觉写实类场景的光照调优不再需要反复试错。2.4 Luminous Studio从“看不见结果”到“所见即所得”的工具链工具链是引擎迁移中最容易被外行低估的部分。Ebony 那一代引擎的编辑器很多是给工程师用的摆个物件、调一个参数经常要重新编译、重新打包、再进游戏验证。而 Luminous Studio 把场景编辑、光照调节、天气参数调整、资源管理全部塞进了一个实时预览环境。美术可以直接在编辑器里拖一个太阳调它的角度和色温实时看到云、雾、阴影跟着变化。这种能力对开放世界迭代效率的提升是决定性的。我在做 3D 渲染项目时一直在强调一个观点编辑器预览效果和真机运行效果如果差得太大团队很容易陷入“调一版进去跑一下、再调一版再进去跑一下”的死循环一天下来干不了几件事。Luminous 在这一点上解决得还算体面至少从 FF15 发布前的内部演示来看编辑器里看到的状态和最终游戏已经非常接近。很多商业引擎做到今天也未必能把这个统一性做明白SE 愿意在工具链上下重注是这次迁移能最终落地的关键原因之一。3. 大气系统体积云、大气散射与动态天气链路如何落地3.1 从天空盒到程序化大气瑞利散射与米氏散射的简化实现老游戏里的天空通常是一张贴图一张日出贴图、一张正午贴图、一张黄昏贴图玩家看到的天色变化靠美术预先烘焙出一整套贴图轮播。这种方式的致命问题在于当太阳被云遮住、或者天气突变时天光颜色和环境光的响应会显得非常不真实因为贴图之间并不会发生真正的物理联动。从 FF15 最终实机的天空表现来看Luminous 在这代引擎里明显做了程序化大气模型。程序化大气的核心是用简化的物理公式计算光线在大气中的散射瑞利散射负责短波长的散射让晴天天空呈现蓝色米氏散射负责气溶胶大颗粒的散射让日落方向的天空泛出橙红色。太阳高度角不同散射的积分结果会呈指数变化所以你会在 FF15 里看到从黄昏到夜晚的过渡极其连续细腻天空既不会瞬间变黑也不会一直维持同一片蓝。当然完全实时计算大气散射的开销不小常规做法是把散射结果预计算成查找表用太阳高度角、视角方向、相机高度这些参数去索引运行时只做采样。从 FF15 画面的天空渐变表现来反推SE 大概率就是这么处理的既有散射的真实感又有足够好的实时性能。这类技术放到今天的商业引擎里已经不算新鲜但在那个阶段能把天空做到这种连续度的作品并不多。对场景美术来说这种程序化天空最大的意义是——你不用再手动去画 20 张不同时段的天空贴图了。3.2 体积云让云层真正有了“体积”FF15 最让人印象深刻的画面里有相当大一部分贡献来自云。暴风雨来临前大团乌云在头顶翻涌黄昏时分被染成紫红色的云层横贯天际这些都是体积云的功劳。体积云的实现原理可以简单类比为在一个覆盖天空的“大盒子”里做射线步进ray marching采样三维噪声和二维天气图计算出视线路径上每个点的云密度再沿视线方向做光照积分最后得到带有体积感的云层颜色。密度越高的地方云越厚实光线穿过云层时会留下阴影和散射颜色观感上和真实云层非常接近。从 FF15 的最终效果看他们的体积云并不是简单的静态噪声叠加而是结合了风力扰动、多层噪声混合和天气遮罩。乌云翻滚时能感觉到云层内部有高速流动的气流这种动画效果需要反复采样噪声函数对 GPU 的 ALU 压力不小。所以我推测 SE 在实现过程中大量使用了降采样先在低分辨率上做 ray marching再做上采样和时域抗锯齿否则 PS4 根本扛不住这种规模的云层模拟。当时能跑出这个质量已经算是把 GPU 性能榨得很干了。体积云的另一层价值是它可以和场景光照真正交互。太阳角度低的时候云层边缘会被打成金色云底会形成大面积的阴影区域这些效果在静态云贴图里几乎不可能模拟。FF15 的黄昏场景之所以被那么多玩家截图收藏很大原因就是这套云层系统把“光线穿过云层”这一物理现象还原到了足够细腻的程度。3.3 昼夜循环、天气与全局光照参数的联动有了程序化天空和体积云昼夜循环就不再是“到点换一张天空贴图”这么简单了。FF15 的昼夜循环大约在现实时间的几十分钟到一小时左右走完一个完整周期循环中几乎每一帧的光照和天气参数都在变化太阳高度角驱动主光源的方向、色温和强度大气散射模型根据太阳角重新计算天空颜色云层密度影响直射光的衰减比例环境光和反射探针也会随着晴雨状态切换而更新。这套参数联动最复杂的场景是雨天和雷暴。雨天时云层快速增厚主光源强度明显下降环境光颜色发灰发冷地面反射增强。FF15 里能看到雨水落在地面溅起水花、车辆驶过带起水雾说明引擎在渲染层面专门做了“雨幕”和“湿地面”的处理。天气系统在 Luminous 里本质是一个拥有状态机的全局系统它会影响到从天空、雾效、粒子到阴影类型的所有可见层。这种全局驱动的好处是玩家在游戏里遇到下雨时不会觉得“只是天空换了个滤镜”而是整个场景的光照、反射、大气都在同一条链路上实时响应。这也是引擎迁移前后差距最大的地方。Ebony 那类旧世代的天气切换往往需要加载不同的光照设置和场景参数做不到这种无缝的实时联动这才是“技术代差”最直观的体现。4. 光源环境从固定灯光编排到分层动态照明体系4.1 旧式三光源打法的局限线性关卡里的过时方案很多游戏场景设计走到现在灯光师还是习惯用三光源思路开场一盏主光负责照亮主体、一盏填充光降低对比、一盏背光把轮廓勾勒出来。这套方法论在封闭线性关卡里非常实用因为镜头和玩家路径基本都是可控的灯光师可以针对每一个转角做手工微调把玩家视野里的画面调整到最有氛围的状态。但开放世界直接把这套逻辑打破了。玩家可以从任意方向进入一个场景白天和夜晚看到的灯效完全不同主光方向永远不固定填充光和背光也就无从谈起。FF15 的世界设计里玩家既会在阳光明媚的草原上开车也会在深夜的城市里穿行固定的灯光编排根本覆盖不了如此复杂的场景组合。Luminous 的解法是把光照拆分成多个层级方向光管太阳和月亮天空光管环境底色间接光管漫反射和反射再用探针和反射源做局部修正。每一层各司其职而不是企图用几盏灯一次性把所有东西都照亮。4.2 方向光与天空光和大气系统深度绑定的光环境在 Luminous 的架构里主方向光承担着非常重要的职责它必须和大气系统保持同步。引擎从大气散射模型拿到太阳的方位和强度之后再更新方向光的颜色、阴影方向和强度。太阳升起时方向光是暖橙色正午时是偏白的冷色黄昏时变成浓烈的橙红夜晚月亮升起时则是一道清冷的蓝光。这种同步不是简单地把太阳贴图换掉而是每一次变化都会重新计算阴影、反射和全局光照的贡献。天空光则负责提供环境底色。在开放世界里天空光其实是来自天穹所有方向的光线积分它的颜色会随着太阳角下降从蓝色逐渐变成紫色、橙色。FF15 黄昏时角色和建筑会蒙上一层暖紫的环境光这不是美术随手调出来的氛围色而是程序化大气计算的自然结果。天空光通常通过环境贴图或球谐函数传到场景中会直接影响物体背光面的颜色。这也是为什么 FF15 的阴影区域从来不是死黑一片而是带着细腻环境色的暗部——这种“暗部有颜色”的特质是区分新旧渲染架构非常直观的一处细节。4.3 间接光、GI 与屏幕空间技术的工程组合全局光照是开放世界游戏里最难啃的骨头之一。真正意义上的实时路径追踪 GI在当时的主机上完全不现实。FF15 用的应该是预计算光照贴图加实时探针加屏幕空间技术的组合大部分静态场景的间接漫反射由离线烘焙的光照贴图提供动态角色和移动物体会采样周边光探针获得环境光屏幕空间反射和环境光遮蔽负责补足近距离细节。这套组合的实际效果是静态场景有稳定的间接光动态物体不会看起来像“悬浮”在场景外面。但工程限制也非常典型光照贴图是预烘焙的场景里的可破坏物件和动态加载物不会自动获得间接光只能靠探针撑住。FF15 在这种细节上的表现不算完美偶尔能看到一些物体在特定角度下和环境光照脱节这是那个硬件世代的普遍妥协算不上 Luminous 的硬伤。对我这种搞渲染的人来说与其吐槽它不完美不如说在开放世界那么大范围内能把 GI 做到这个统一度已经能看出 Luminous 的工程投入有多大了。4.4 体积光、阴影级联与灯光的细节取舍说到 FF15 的光源环境绕不开那个被大量玩家拍照传播的体积光效果。穿过树叶缝隙的丁达尔光束、教堂窗户射进来的灰尘光柱、路灯下雾气里的光晕这些效果大量出现在游戏场景里。实现体积光常见的方式有几种一种是在全屏后处理阶段做光线步进另一种是对光源体积做近似追踪。考虑到 FF15 场景里存在大量点光源和聚光灯SE 大概率采用的是屏幕空间的 light shaft 方案配合深度信息生成光束既控制住了开销又能覆盖大部分场景。阴影方面室外主光源用的是级联阴影贴图CSM把视锥体按距离切成近、中、远几个级联每一级使用不同分辨率的阴影贴图。FF15 的阴影在近处很锐利远处慢慢变虚变淡这是多级联加 PCF 过滤的典型效果。室内灯光和人造光源不太可能都开动态阴影因为动态阴影填充的开销太高开发团队通常只会在关键道具和主要角色身上保留动态阴影。这个决策思路我在自己项目里也用过光源再多能开动态阴影的永远是少数把有限预算花在玩家视线焦点上比让所有灯都开影子划算得多。5. 资产管线迁移最容易被低估的硬骨头5.1 场景与地形迁移坐标、单位和光照烘焙的连环雷引擎迁移中最基础也最磨人的坑发生在底层数据格式的转换上。Ebony 和 Luminous 对场景数据的组织方式很可能完全不同坐标轴朝向可能是 DCC 惯例的 Z 轴向上和游戏惯例的 Y 轴向上打架单位比例可能是 1 unit1 cm 和 1 unit1 m 混用模型导进去之后整个城市被反转、放大百倍的状况并不罕见。我做过这类转换第一次打开迁移后的场景发现所有建筑都朝天上飞、角色缩成一粒米的时候那个心情真的很崩溃。地形方面更麻烦。FF15 的开放世界不是简单的一张高度图它有大量道路、河流、山体、洞穴入口这些在引擎里往往依赖地形系统特有的数据结构。旧的 Ebony 地形数据到了新引擎通常不能直接复用要么重新雕刻要么花力气写转换工具。光照烘焙又是一笔额外账旧引擎的 Lightmap 布局完全作废因为 PBR 材质和实时光照系统要求全新的 UV 展开和烘焙参数所有关卡都需要重新展开 UV、重新计算间接光数据。这个流程是以“周”为单位消耗工期的而且很难通过增加人手来加速。5.2 材质系统切换从旧式贴图通道到 PBR 工作流的转换这是资产管线最集中的痛点。老的材质系统普遍是 specular/glossiness 工作流一张漫反射贴图、一张高光贴图、一张光滑度贴图。Luminous 的 PBR 管线用的是 metalness/roughness漫反射、金属度、粗糙度。两种工作流的物理含义不一样直接用算法把高光贴图转成粗糙度贴图很容易得到金属像塑料、粗糙度数据完全失真的结果。转完之后美术还得逐个材质检查手改周期非常长。从我对 FF15 画面的观察来看金属机械和光滑地面的表现是相当稳定的说明团队在转换时应该做了大规模的人工修正或者开发了比较智能的转换工具能把旧的高光贴图按灰度分布合理映射到金属度和粗糙度通道。但不管工具多智能总会有材质无法自动收敛必须依靠美术逐张手工重绘。这种工作量和耐心的消耗是整个引擎迁移周期里最隐性的成本。还要注意一点PBR 工作流并不是万能的。FF15 里诺克提斯衣服上的反光、角色皮肤的半透明质感明显走了额外的材质模型或者更精细的着色器分支。这种特殊材质的开发和验证在 Ebony 时代可能已经做过一版但换到新引擎后一切都要从头配一遍才能保证画面表现达到预设标准。5.3 角色、动画与工具链迁移版本里的隐性重做角色模块的迁移是另一个大头。角色的骨骼层级、蒙皮权重、动画状态机、物理布料解算、面部表情通道全部要在新引擎里重新导入和验证。如果 Ebony 和 Luminous 的骨骼命名不一样、绑定姿态不同、动画系统不兼容那整条角色管线基本等于全部重做。从 FF15 最终的角色表现来看诺克提斯头发的飘动、披风在跑动时的物理解算都非常细腻这些效果大概率不是从旧引擎带过来的更像是 Luminous 为 FF15 专门开发的全新角色渲染链路。工具链层面的差异同样致命。Ebony 时代可能积累了大量只服务于旧管线的内部脚本和 DCC 插件切换到 Luminous 后这些插件全部作废。DCC 里的资产导入导出、资源版本管理、自动化打包流程都必须重建。这些工作看起来不起眼每一项都在消耗真实的工期。很多团队在做引擎迁移评估时只关注渲染效果和功能清单忽略了工具链重建才是决定项目能否按时交付的胜负手。我现在做任何引擎相关决策时都会把工具链成本单独列一个科目去评估吃过亏的人才会明白这部分有多痛。6. 实机表现与性能平衡迁移最终值不值6.1 玩家看得见的改变天黑之后画面才真正发光如果只看白天的草原和公路FF15 给人的第一印象可能只是“这游戏画面还挺精致”。可真正让它被反复截图传播的画面几乎全部集中在灯光和大气的表现上黄昏时被金色光线打亮的云层、夜晚城镇里霓虹灯光在水洼里的倒影、篝火旁角色皮肤上的暖色反射。这些场景在旧的 Ebony 引擎里很难出现因为它们太依赖实时动态光照和大气的共同作用了。Luminous 的引擎名本身就代表着“光”的意象FF15 也确实把“光”做成了游戏的视觉名片。玩家驾驶跑车向晚霞方向驶去太阳从车头方向把光线打进车内那种连续、真实的光环境变化是引擎迁移最直观的价值证明。对一个以“光”为核心审美的项目来说Ebony 做不出这种效果这不是美术能力的问题是底层渲染架构根本性的差距。6.2 主机与 PC 平台的性能预算差异技术取舍的现实账本FF15 在主机上的基准目标是 30 帧。PS4 初版在画质模式下的分辨率并不算高动态分辨率也使用得很频繁。PS4 Pro 和 Xbox One X 推出后才在增强机型上实现了更高分辨率的表现PC 版则依托更强的显卡进一步提升了渲染特性。这说明 Luminous 在主机上为了支撑那套大气系统和光源环境其实已经做了相当多的性能取舍。大致做个粗略的性能拆解体积云的分辨率、GPU 粒子数量、阴影级联数、SSAO 采样数这些参数在主机上一定是被压到“刚好能看”的水平。PC 版可以开更高的体积云反射采样、更远的阴影距离所以 PC 版的画面明显更强。对玩家来说这很自然对开发者来说这意味着同一套光照和大气系统要在不同性能档位下都能产生可以接受的视觉效果Luminous 做到了这一点说明它在参数化和可扩展性上的工程做得是合格的。6.3 这次引擎迁移留下的几条可以复用的经验复盘完整件事我最大的体会是引擎迁移表面上是个技术问题本质上是产品决策问题。Ebony 被放弃不是因为它“差”而是因为它和 FF15 的目标形态彻底错配。这段经验如果提炼成方法论大概是在项目早期就确定目标平台和目标玩法形态再决定用商业引擎还是自研引擎能省掉后面无数个不眠之夜。第二点经验是资产标准一定要在迁移启动的同时建立。如果旧资产已经有一套统一标准转换工具的开发就能做得很顺如果团队之前一直是各做各的迁移时连转换脚本都很难写出来因为输入数据没有一致性。FF15 中角色、车辆、场景的材质统一度还算高说明团队在迁移时期的组织能力是非常强的。第三原型验证必须先行。开发一个能跑通地形流送、昼夜循环、体积云、CSM 阴影的技术 Demo确认性能在可接受范围以内再让所有内容团队进入批量迁移。从 Luminous 的技术 Demo《Agnis Philosophy》来看SE 显然是把这条准则贯彻了——先有可信的技术验证才敢把全项目押上去。最后再补一句个人体会。我陪跑过几次引擎级的迁移项目越来越确认一件事团队做迁移时最容易被忽略的不是技术方案而是让所有人对“为什么换、换了会怎样、不换会怎样”形成统一认知。FF15 的这次迁移最终能成功交付除了 Luminous 的技术底子更离不开项目组在方向和取舍上的坚持。如果你正站在要不要换引擎的岔路口希望这篇研究报告能帮你把账算得更清楚一点。