我作为一个玩家,很少会停下来盯着一道游戏里的瀑布看。但在《HAWKED》里,你可能会觉得那些水流有点“不对劲”——不是因为它做得差,而是它太精准了,每条瀑布都卡在场景里最合理的位置,动态、形态甚至流速都像是在说话。
Serge Filin 是 MY.GAMES 的资深程序化技术美术兼工具开发者。他跟我讲这件事时,语气里有一种“终于把事干成了”的轻松。在《HAWKED》这个项目里,他负责搭出一套能自动生成瀑布的工具。目的很明确:不再让关卡美术师把概念图里的瀑布一条条手工抠出来,而是让工具自己去“读”原画,然后生成 3D 实时材质。
这个过程,他复盘得挺详细。
“做这套工具,本质上是在回答一个问题——怎么把 2D 概念艺术翻译成能在虚幻引擎里跑动的、带有实时反馈的动态材质?”Serge 说,别看瀑布这东西在游戏里好像只是个背景板,一旦你手工铺,量一大,地形稍微一改,所有摆放就全白瞎了。团队需要的是灵活的、能适应地形变化的流水系统。
他最早遇到的挑战倒不是代码,而是概念。2D 原画师画瀑布有自己的美学逻辑,水从哪起、在哪溅开、哪个位置水雾多,都是视觉引导。但到了 3D 场景里,地形是动态的,镜头会转,日照会变,一条直愣愣的贴片水流看起来就假。
Serge 决定先从数据源头解决。他让工具读取概念图的关键信息——比如瀑布起点位置、大致落差、水流宽度,以及侧重点是在“下落感”还是“冲击感”。这些信息被转成一种内部参数模板,然后工具在虚幻引擎 5 里生成对应的样条线。样条线沿着地形的实际高度走一遍,就能自动拟合出适合当前地形的瀑布形态。这样一来,美术师不需要手调每一条瀑布,只需要定义起点、方向和风格偏好,剩下的就交给工具去算。
水本身的表现,他用的是 Master Materials(父材质)那一套。不同瀑布会被分配不同的材质实例,动态水雾、飞溅泡沫、流速变化都靠参数控制。这样有一个好处:当太阳角度改变时,瀑布上的高光和折射也能跟着实时变化,而不是那种死板的、永远一个光照结果的预烘焙效果。
“有一点很关键,”Serge 提醒我,“瀑布不是孤立存在的。它撞击到岩石有什么反应?流到平缓处是不是变成浅滩?这些过渡,是让玩家觉得真实的核心。”所以工具里专门加了“过渡态”逻辑——从陡坡到缓坡、从单股水流到多股分流,都会根据地形自动切换材质混合参数,而不是粗暴地拼两个东西在一起。
他还特意强调了 Houdini 在其中的角色。整个生成逻辑,包括样条线分析、地形采样、水流方向计算,都是在 Houdini 里做的,然后打包成 Houdini 数字资产(HDA)。到了虚幻引擎 5 里,通过 Houdini Engine 就能直接调用,既保留了程序化的灵活性,又不用开着外部软件来回倒腾。
这套工具后来不光用在《HAWKED》,在《War Robots Frontiers》里也派上了用场。Serge 对这点挺满意:“一套工具能跨项目复用,说明它确实解决了真问题,不是那种‘这个项目特供’的一次性脚本。”
但我也问了他一个比较实在的问题:程序化,到底省了多少事?
他想了想,没给具体数字,但描述了一个场景:以前一个关卡如果要调整地形,瀑布往往得跟着重做,因为水流路径完全靠手摆。现在只要你改了地形,点一下生成按钮,所有瀑布会自动重新计算路径、流速、水雾区域,十几分钟的事,以前可能要半天。
当然,程序化也不是万能药。Serge 坦言,有些特别讲究构图的场景,还是需要美术师手动微调。工具负责解决 80% 到 90% 的重复劳动,剩下那一点“艺术判断”,还得人去做。“就像自动曝光再好,有时候你还是想要手动挡,”他说,“但至少你不用从拧螺丝开始造车了。”
开发过程中,他也有过卡壳的时候。因为要处理的水流类型太多——垂瀑、多层阶梯瀑、山涧流——每种对材质、粒子、样条线的要求都不一样。最开始,他试图用一套万能逻辑把所有人套住,后来发现不行,才改成“风格标签”的方式:允许每段样条线带多个属性标签,工具再根据标签组合去读对应的规则库。
这个“风格标签”的点子,其实是从他之前做摄影测量时养成的习惯里来的。那时候他负责给电影《银色溜冰鞋》做全流程高精度摄影测量资产,很早就习惯了把“对象属性/分类/质量标准”作为一项资产的核心元数据。现在用到游戏里,恰好能解决“一个工具面对多种美学需求”的问题。
说到摄影测量,Serge 回忆了一下。他最早入行就在 VFX 那边做摄影测量,后来成为那部电影的技术指导,负责从拍摄到最终交付的全周期。也是那时候,他第一次接触到 Houdini,立刻意识到这东西才是他想干的。“其实那会儿我就发现,我更喜欢实时图形,而不是传统 VFX 那种离线渲染,”他说。后来《银色溜冰鞋》成功发行,甚至上了 Netflix 的精选榜,他就转向自由职业,做了几年 3D 环境美术师,建模、雕刻、贴图、烘焙都干过,把标准游戏开发管线摸了个熟。
但那个阶段他有个心结:怎么把 Houdini 真正融进游戏生产流程里?传统环境美术的流程是手动的、迭代式的,Houdini 的程序化思想有时候会跟这个打架。他想不清楚,就去请教了 The Mentor Coalition 的创始人 Josh Lynch。聊完之后,方向就清晰了——专门做 Houdini 到虚幻引擎的程序化管线,ArtStation 上也开始密集地放这方面的作品。大约一年后,他接到了第一个程序化美术的小项目,再做几个月,机会就多了起来。再往后,就进了 MY.GAMES。
回头看这段经历,Serge 觉得最有价值的不是他写了多少行 VEX 或者会多少 C++ 补丁,而是他开始理解大厂到底需要什么样的内部工具。“工具不是证明你多聪明的展品,而是让别人工作得更好的东西,”他说。这句话大概是一个工具开发者转型后最实在的体会。
所以当我再回头看《HAWKED》里那些瀑布时,它们已经不是单纯的“风景”了。每一道水流的背后,都是一套规则在计算地形、材质、过渡态和光照,而且这些规则会随着关卡迭代持续自我修正。玩家可能永远不会知道,但那种“瀑布就该在那里”的舒服感,就是程序化工具成功的地方。
至于未来,Serge 没做什么宏伟的展望,只说他会继续研究实时图形里的程序化可能性。但有个方向他提了一嘴:能不能把这种“从概念图到实时材质”的翻译,再往前推一步,让美术直觉和程序化逻辑之间的摩擦变得更小?他没说具体方案,但我猜,他的 Houdini 里可能已经有新的节点在长了。