一濑泰范关于在ns上怎么使用re引擎开发和优化rise的访谈
本帖最后由 LiberaMe 于 2021-6-29 19:44 编辑怪物猎人:崛起已经推出了几个月，销量惊人，同时也展示了Switch硬件在合适的开发者手中所能表现出的能力。作为该系统上仅有的两款使用RE引擎的游戏之一（另一款是《魔界村》），它在任天堂硬件上将该系列带到了一个新的层次，同时成功保留了上一代作品的视觉外观和魅力。
然而，它的技术方面很有趣。《怪物猎人：世界》似乎超出了任天堂平台可以表现的能力，但该游戏的许多更新方法却在《rise》中得以体现。有许多加载屏幕的分段地图的日子被无缝的开放区域所取代，而新的游戏内容使玩家能够快速甚至垂直地穿越环境。虽然mhr和mhw的视觉风格不同，但它们的共同点远比许多人可能意识到的要多。
这一点最近得到了加强--我们得到了机会向《rise》的总监一濑泰范提出问题。这次采访的重点是游戏的技术发展，当然还有卡普空的RE引擎的实施。
在任天堂Switch上的《rise》利用RE引擎的主要原因是什么？
主要的原因是，我们可以使用RE ENGINE强大的C#脚本系统，更不用说RE ENGINE的最新图形功能（如果硬件规格允许的话）。在MT FRAMEWORK中，所有的游戏逻辑都是用C++实现的，所以构建时间是个问题；在RE ENGINE中，游戏逻辑是用C#实现的，所以构建时间可以大 大缩短（大约10秒，在C++中需要100倍的时间）。这允许快速迭代试验和排除错误，使游戏更加有趣。这不是直接可见的，但它是开发中非常重要的一部分，我认为它间接地促进了游戏的乐趣。
与《魔界村》一样，这是在任天堂的硬件上利用引擎的一个罕见的例子。RE引擎的核心团队在多大程度上调整了工具以适应Switch？
RE ENGINE的设计从一开始就考虑到了多平台的问题，所以简单的移植本身并不那么困难。然而，要与核心图形元素（涉及ns的略微独特的图形API—NVN）合作，为着色器程序开发一个翻译器是相当困难的。
在RE ENGINE中，着色器程序是用HLSL（高级着色器语言）编写的，但我们必须实现一个新的翻译器，将其转换成GLSL（OpenGL着色语言）。在这个翻译器中，我们实现了一些技巧，以便在从HLSL转换到GLSL时输出最佳代码，这样就可以实现GPU的性能。我们还专门为任天堂Switch的GPU增加了支持。例如，我们增加了对ASTC（自适应可扩展纹理压缩）的支持，这种纹理压缩格式对减少内存和数据大小非常有用。
RE引擎的早期测试和为Rise计划的视觉效果是否得到了强有力的结果，还是需要进行重大的优化以达到你想要的性能？
最初的性能问题相当严重，主要的优化工作是必须的。首先，我们将图形管道从延迟渲染转换为正向渲染。在过去，RE ENGINE使用了一个基于延迟渲染的图形管线。然而，由于Switch的内存带宽有限制，我们为《rise》重新建立了一个新的正向渲染图形管线，然后从大到小逐一进行了许多优化。
这些优化的例子包括：烘焙/应用阴影，应用GPU Occlusion Culling（遮挡剔除），以及用新的轻量级替代方案取代DOF（景深）等。
我们还进行了许多其他的优化，包括：用简化的计算方式取代过于严格的计算方式，用像素着色器的实现方式取代Compute Shader的实现方式，以及增加一个剔除过程。我们还与场景美工合作，调整了光影的影响范围，因为在有太多光源的地方，计算负载会变得过于繁重。
和之前的《mhw》一样，《rise》利用了更大的无缝环境，这种方法最大的好处是什么？
在《rise》中，你现在可以执行高度灵活的行动，如跑墙和使用翔虫。你还可以在骑着一个叫Palamute的新伙伴角色时快速地在场内行动，这与无缝环境配合得非常好。
虽然这是一个新的引擎，但视觉设计确实与之前的Wii、3DS和Wii U作品有相似之处。你能解释一下你是如何是在更高的分辨率和细节水平上表现这些怪物的外观的？
为了使《rise》的新怪物与过去模型规格截然不同的怪物处于同一表现水平，我们在与负责动作处理的团队反复核实后，谨慎地进行了纹理、多边形数量和关节数量的设计。毛发是最困难的部分，但当《mhw》的着色器可以移植过来时，这个问题就解决了。
你能谈谈这个项目中的大量动画工作吗？例如，与之前的3DS游戏相比，这代表了多大的进步？
由于Switch的规格，使用3DS时代的数据是最简单的，但由于《怪物猎人：世界》是最近才发布的，所以尽可能让《rise》的表现看起来现代是很重要的。从处理的角度来看，最好是关节少，动作柔和，表达自由度高。这是我们不想削减的元素，所以我与程序员紧密合作并协商让来自《怪物猎人》中的角色尽量保持原样，而一些新的角色则是通过与模型团队协商后创造出来的，我们直到最后一刻才减掉多余的关节。当涉及到面部动画时，《mhw》的充足的结点数量是一个不可能的数字，所以我们努力为这个游戏敲定数量，然后再进行面部动画的制作。
至于动画工作，我们首先要确保《mhw》的数据可以移植过来。修改和减少链条和辅助关节是一项需要模型师和程序员更多工作的任务。
除了《mhw》中的攻击和动作外，"Wyver "也是一个很好的例子，"Wyvern Riding "作为一项新功能被添加到《rise》中，因此我们需要创建的动作数量大 大增加。创建攻击、动作和技巧所需的时间很高，而且由于 "Wyvern Riding "动作也被加入，由于材料的数量、创建时间和后期的检查，负责敌人的动画团队也很辛苦。
在玩家方面，因为加入了很多涉及翔虫动作的空中动作和使用墙壁的额外动作，所以除了内部捕捉外，我们还得到了活剧座（动作mo-cap团队）的帮助来提高质量。
对于NPC，我们专注于调整每个NPC在这个游戏中的位置和相关性的变化。我们希望你们会喜欢这些细节，例如当你来到他们的村庄时，NPC和你打招呼的方式，或者当你从一个地区移动到另一个地区后，NPC位置的变化。
在使游戏看起来和表现如此出色的步骤方面，你最引以为豪的是什么图形技巧和调整（例如降低远处生物的帧速率，分辨率调整）？
在游戏过程中没有用到流式贴图传输，但在过场中这么做了，NPC是流式贴图的，在高分辨率mipmap部分加载时能使其分辨率更高一些。这使我们能够在游戏过程中减少内存的使用，同时使切割场景看起来更加完美。rise中的图形是许多精细的技巧和调整的结合，我们对它们同样感到自豪。
背景中的小物体（道具）在远处时会被抹去，但如果它们突然消失，视觉上会显得很突兀。因此，我们使用了一个抖动模式来逐渐擦除它们，这样它们就不会很突出，我们还手动调整了擦除个别项目的距离。由于在正向渲染中没有G-Buffer（几何缓冲），所以在延迟渲染中经常使用的技术（SSAO和SSR）不能按原样使用，但它们是以一种创造性的方式实现。
SSAO（屏幕空间环境遮蔽）的深度数据源于普通的深度缓冲。SSR（屏幕空间反射）是通过为水面增加一个专门的渲染路径来特别支持的。
水面的反射是我们特别努力的部分（即使它增加了一些处理负荷），因为我们想让它看起来真实而美丽。此外，在Fog中还包括了一个简单的大气反射特效，仅仅增加一点处理负荷却很有助于使背景光的表达看起来更华丽一些。
如果你能穿越时空，在《rise》的开发之初给自己一些建议，你会怎么做？
我认为我们应该早点创造一个自动测试性能的环境。mh系列里有各种各样的阶段、怪物、武器类型等的组合，所以我们没有一个涵盖所有这些模式的自动测试的环境使得我们在检查优化结果时有些困难。
在任天堂Switch上用RE引擎制作《怪物猎人》之后，您的总体感觉是什么？
优化是非常困难，但也是具有足够挑战性和回报的。由于RE ENGINE的基本设计、工具和开发方法，我们能够持续挑战优化直到开发过程的最后一分钟。要把大型的RE ENGINE装入小型的Nintendo Switch，这是一个挑战，但我很高兴我们能够创造出在Switch上能以这种质量运行的让人们印象深刻的游戏。
https://www.nintendolife.com/new ... re_engine_on_switch
翻译是deepl机翻以后手动润色的结果，可读性应该还行
这破rise太难做了，优化起来累的要死，头发都掉光了，才不要再更新内容活受罪了。 从结果来说MHR在NS上的效果真的非常棒了 这优化可是够累的 本帖最后由 GuardHei 于 2021-6-29 20:20 编辑
吹的有点过了，哪里就超出ns硬件水平的图像了...
看到前向渲染喷了，没想到是这样。主机模式900p都没有就嫌带宽不够了，隔壁荒野之息最低分辨率还是mhr最高分辨率也照样延迟渲染啊。不过没看出来有ssao啊，按他的意思是靠深度缓冲重建，但根本看不出效果啊。ssr也是的，这么低的分辨率和精度明显不是sspr，都没啥好吹的吧...
毛发确实应该是渲染开销大头。特殊的轻量级dof不就是降分辨率+不剥离前后景吗，人物边缘有一圈明显的edge bleeding。这有什么很独特的地方吗？
总体感觉还是拉了...再一看实现方法果然也感觉就是多平台再顺手移植ns一份。
—— 来自 S1Fun 所以现在MHR成绩如何 就看了前面一段，c艹改c#效率提高100倍？？？ yangyus1 发表于 2021-6-29 20:29
就看了前面一段，c艹改c#效率提高100倍？？？
cpp编译就是慢啊..
—— 来自 S1Fun 我是地雷我自豪 发表于 2021-6-29 20:20
所以现在MHR成绩如何
本土接近220万全球早就五百万卡表都笑不动了 yangyus1 发表于 2021-6-29 20:29
就看了前面一段，c艹改c#效率提高100倍？？？
用c++编译一次不到20分钟，还挺快的
—— 来自 OnePlus HD1910, Android 11上的 S1Next-鹅版 v2.4.4.1 re引擎真是个好东西 GuardHei 发表于 2021-6-29 20:13
吹的有点过了，哪里就超出ns硬件水平的图像了...
看到前向渲染喷了，没想到是这样。主机模式900p都没有就嫌 ...
荒野之息的水平确实不好达到
不过那个卡通化渲染也相对省些机能吧？ foreverbelmont 发表于 2021-6-29 20:50
本土接近220万全球早就五百万卡表都笑不动了
全球早都破700万了...但还是要吐一口唾沫再走 hzhh95963 发表于 2021-6-29 20:54
用c++编译一次不到20分钟，还挺快的
—— 来自 OnePlus HD1910, Android 11上的 S1Next-鹅版 v2. ...
看差了，没看到是编译。本能以为是运行效率。 狂吹的优化如何？ LiberaMe 发表于 2021-6-29 23:48
荒野之息的水平确实不好达到
不过那个卡通化渲染也相对省些机能吧？
荒野之息的卡通渲染最主要省的地方在：1. 缺少高光细节所以可以在半透明水面后面以1/4分辨率来着色用来降低overdraw；2. 贴图内存不会很高，而且远景贴图可以通过过渡向纯色来解决贴图重复平铺的问题；3. 人物脸部渲染可以省事。
但是除此之外，荒野之息整体画面复杂度上远胜于mhr。而且就这三点来说，mhr远处地形贴图平铺完全不处理，贴图压缩出来的artifact看着非常明显。水面本身ssr分辨率就很低而且不透明度也很高，人物脸部在过场里确实有很好的模型和sss效果，但是实际游玩时这种全阉割了，观感就那样。就这样mhr比起botw还缺了一堆特效，分辨率远远不如，而且在水没林地下那块掉帧还挺严重的
mhr最割裂的地方就在于过场画面和游戏画面完全是两个概念。过场画面也是实时渲染的，无论是分辨率还是模型特效都远胜游戏实际画面。如果游戏里全程画面都有过场画面那么好，那叫超越硬件还差不多
—— 来自 S1Fun 又黑C艹编译时间 卡普空真正让人觉得超越机器机能的作品其实是生化启示录一，当初用3ds玩的，就算是在那个马赛克屏幕上效果也非常惊人。 Messiah_ 发表于 2021-6-30 01:21
卡普空真正让人觉得超越机器机能的作品其实是生化启示录一，当初用3ds玩的，就算是在那个马赛克屏幕上效果 ...
3ds的机能能整成那个水平确实吊 这就是护石系统做那么恶心的原因吗，呸 丹德里恩 发表于 2021-6-30 10:13
这就是护石系统做那么恶心的原因吗，呸
这系统怎么个恶心法 zhangqq_008 发表于 2021-6-30 15:27
这系统怎么个恶心法
炼金要怪的素材，每种素材的点数不同，从下位怪的皮毛值20点到古龙玉100点不等，后期一般选词条全随机的一档（150点数炼一个、一组最多5个、一次性最多10组），想功利炼金只会去打特定那几只好欺负的（雷神龙、爆鳞龙etc）
然后还不直接告诉你结果，要你先出门去打一盘回来就会炼好一组（即5个）
等你一口气刷完十把回去开这50连发现全是垃圾、自己浪费时间素材也没积攒的时候，很难绷得住
还有一个护石回收服务，让你用20个垃圾换成3个新垃圾，也得打一把 卡表优化一直没得说
当年7300le能玩鬼泣4真把我震惊到了 丹德里恩 发表于 2021-6-30 15:53
炼金要怪的素材，每种素材的点数不同，从下位怪的皮毛值20点到古龙玉100点不等，后期一般选词条全随机的 ...
所以yltf和tgy哪个更屎 Xerxes_2 发表于 2021-6-30 17:29
所以yltf和tgy哪个更屎
都是故意给玩家找不自在的2坨屎用不着区分哪个更臭 丹德里恩 发表于 2021-6-30 15:53
炼金要怪的素材，每种素材的点数不同，从下位怪的皮毛值20点到古龙玉100点不等，后期一般选词条全随机的 ...
这tm怎么整的跟手游似的
卡婊也有日活这种kpi要求莫非？ zhangqq_008 发表于 2021-6-30 19:35
这tm怎么整的跟手游似的
卡婊也有日活这种kpi要求莫非？
现在的手游都没有那么弱智，不会纯粹是浪费时间 不如吹吹一个动作游戏动作系统充满了bug，输入窗口全是没优化过的，甚至连按键配置都没优化的神奇制作能力吧一**泰屎 着色器程序是用HLSL（高级着色器语言）编写的，但我们必须实现一个新的翻译器，将其转换成GLSL（OpenGL着色语言）。在这个翻译器中，我们实现了一些技巧，以便在从HLSL转换到GLSL时输出最佳代码，这样就可以实现GPU的性能。
可能是HLSL -> SpirV -> GLSL，这也是目前常见手段了，优化技巧可能是半精度浮点计算映射，也是移动平台的标准优化方法。
背景中的小物体（道具）在远处时会被抹去，但如果它们突然消失，视觉上会显得很突兀。因此，我们使用了一个抖动模式来逐渐擦除它们，这样它们就不会很突出
LOD Dither，自孤岛危机以来业界的标准技术。
SSAO（屏幕空间环境遮蔽）的深度数据源于普通的深度缓冲。
这里原文的意思是，通过depth buffer重建法线，这是SSAO的常见做法之一。但不知道前向渲染管线之下，要怎么正确的混合SSAO结果（除非是前一帧的depth）。
SSR（屏幕空间反射）是通过为水面增加一个专门的渲染路径来特别支持的。
估计是水面shader里直接做ray marching了，这种方法相比标准的SSR，效果会打不少折扣。
总而言之，Rise的优化使用了移动平台上相对比较成熟的技术，没有太多激进的地方（鬼泣、生化危机也是如此，很少会有激进的技术选择）
不过Switch上使用前向管线非常奇怪，塞尔达可是标准的延迟管线跑的毫无问题，手游用前向更多是为了省电而不是提升帧率。
本帖最后由 GuardHei 于 2021-7-1 02:47 编辑
lostyzd 发表于 2021-7-1 02:31
可能是HLSL -> SpirV -> GLSL，这也是目前常见手段了，优化技巧可能是半精度浮点计算映射，也是移动平台 ...
你有看出来用了ssao吗？我是根本没发现...
而且很奇怪的是我不明白为什么很多特效要用ps来实现。switch本身就是dx12级别特性，又不是移动端要考虑兼容性，干嘛不想办法用上async compute而是全靠ps。这也没感觉哪里专门优化了
—— 来自 S1Fun c语言天下无敌? 省下点优化的时间优化优化 UI 逻辑、回馈机制这些问题多好，真实毒瘤平台 switch 的显存带宽非常低，只有 25GB/s。作为对比，ps4 pro 是 218GB/s；1080ti 是 484GB/s。
塞尔达用顶点颜色直接着色，贴图是比较少的，对于 mhr 来说肯定不能这样做，25GB/s，延迟渲染太勉强了。 丹德里恩 发表于 2021-6-30 21:39
现在的手游都没有那么弱智，不会纯粹是浪费时间
明日方舟表示不服，看录像带去吧
页:
[1]
2