为什么不预先渲染游戏中的故事部分?


55

如今,在玩游戏时,经常会遇到与故事相关的过场动画,在这种情况下,您无法与游戏互动,只能在游戏过程中听或观看游戏。

但是,在许多游戏中,这些故事场景是使用游戏引擎而不是使用预渲染的视频实时渲染的。我似乎无法理解为什么在游戏开发过程中未预先渲染故事场景

我的问题是:

为什么不在游戏开发过程中将故事过场动画预先设置为具有最高设置的视频,以使用户不需要在其末端渲染它?

我的猜测是,游戏开发者不会选择这样做,因为视频和实时游戏渲染非常需要平滑过渡。


27
还有资产规模。使用引擎渲染,您只需存储动画数据。高分辨率的预渲染意味着千兆字节的数据。
Almo

55
我不能告诉你,如果已经知道这一点,但仅供参考大多数游戏使用的做好自己的过场动画与分段电影。他们实际上搬到远离从做这样的说法。特别是,请参考Playstation上的FF7和8。
2015年

4
以及过去的美好时光,他们在过场动画中使用实际演员(例如绝地武士),而不是渲染演员(例如在绝地武士的扩张中)
SztupY15年

3
@jhocking点!别忘了FF10!
MonkeyZeus

4
实际上,整个游戏仅包含预渲染的场景(一些较早的冒险)。那时,以高品质渲染3D场景是一个大问题。
温德拉

Answers:


92

我可以想到几个原因:

  • 预渲染和录制视频在磁盘上花费了很多空间,从而使视频与骨骼动画一起生动起来。
  • 视觉方面。如果您以“更好”的质量预渲染了游戏中看到的内容的一半,则过渡可能会使游戏失去流畅性。我可以按照游戏的主要角色进行成像,该角色在正常游戏过程中使用1000个多边形进行渲染,但突然看到他用2000个多边形,良好的皮肤平滑效果和25种着色器效果进行渲染,此过程持续了两分钟,然后以低分辨率跳回角色...这看起来很奇怪。
  • 内部认可/修改过程。我猜想,从游戏公司内部简单地为剪切场景修改动画的流程比修改动画的原始资产,渲染并获得批准要简单得多。
  • 不需要它(或“因为他们可以”)。游戏引擎和硬件变得越来越复杂和强大,因此它们产生的质量越来越接近电影品质的图形,因此既然最终用户机器可以做到,那么为什么还要花些时间进行预渲染呢?
  • 流。正如您所建议的那样,除非您推动引擎执行此操作,否则在显示视频之前可能需要很短的加载时间,而过渡到过场动画意味着要加载较少的数据量和较小的游戏状态过渡。

从评论中建议:

  • 成本。使用具有优化预渲染场景的体系结构的软件(例如Rad Game Tool的“ Bink Video”),许可和实施的成本可能很高。(感谢@Honeybunch)

  • 定制化。如果玩家可以更改其角色的外观,设备或聚会的组成,则这些选择将不会反映在预渲染的部分中(例如,始终显示规范的角色/负载/聚会),或者会显示许多预渲染的视频要求涵盖所有可能的组合(如果玩家有很多选择,这很快就变得不切实际)。(@DMGregory和@Kevin)


8
最后一点实际上以一种棘手的方式与其他人有关。游戏开发人员过去常常使用预先渲染的过场动画,因为引擎中的图形不够好(即他们必须这样做),但由于其他原因,他们尽快停止了这样做。
2015年

7
我认为,尤其是在从预先渲染的过场动画过渡的过程中,许多开发人员正在实时地证明他们可以做到。看到预告片带有夸大的承诺“您将要看到的所有内容都是实时呈现的”仍然不罕见-这种观点是一个卖点,有时退回到预先渲染的东西有时被认为是“作弊”或试图掩盖不符合任务要求的游戏引擎。同样,实时过场动画可以反映玩家的角色/派对定制,而预渲染的每个组合都需要包含视频。
DMGregory

5
If you pre-rendered half of what you see in the game with "better" quality, the transition could make the game lose it's flow.对,就是这样。例如,在《最终幻想8》中,这种效果非常明显(而且令人震惊),无论如何,至少对于PS 1,游戏中的图形本来就已经非常好,但是突然之间您遇到了过场动画,一切看起来都不同,因为您在电影而不是游戏引擎中。
梅森惠勒2015年

42
还有一点:如果玩家角色可以自定义任何内容(即使是非常简单的衣服颜色),玩家也会注意到您预先渲染的过场动画与他们的自定义设置不符。否则,您必须为每个可能的或不可能的自定义角色预渲染单独的过场动画(例如,尝试预渲染每个可能的Commander Shepard或Dovahkiin)。
凯文(Kevin)

7
您忘记了另一个重要的问题:实时过场动画可以使游戏以完全选定的显示分辨率进行渲染。使用预先渲染的过场动画,放大或缩小比例以及不同的宽高比都将看起来很糟糕。
Keavon

44

许多游戏都允许角色在游戏中更改外观。在引擎中渲染场景可以反映这些变化。对于视频,您没有灵活性。


31
当您的角色穿着可能会发现的最古怪的服装而参与严重的过场动画时,这可能会带来搞笑的后果。
BenM 2015年

3
我同意,我认为这是Saints Row之类的游戏的全部要点:)
Brian Rasmussen

3
我记得有一个游戏确实存在此问题(哥特式1和哥特式2)。通过在游戏中进行下去需要特殊的服装来解决(因此服装与渲染场景中的服装匹配)。可能有趣的另一点是未来的计算能力。现在,较早的游戏上市后就可以以更高的分辨率和细节进行播放。根据场景的制作方式,游戏质量可能会高于场景。
Skalli 2015年

6
@BenM。这让我想起了《刺客信条4:黑旗》,玩家可以在其中穿上带帽或不带帽的服装。但是,由于刺客的官方长袍带有兜帽,因此我们得到过场动画,爱德华试图用兜帽遮住他的脸,即使他目前的着装没有。看起来真傻。
Nolonar 2015年

2
这是我们使用引擎内过场动画而不是渲染的100%原因。能够在Maya中进行过场动画将为我们节省大量工具开发,并且蓝光上有足够的空间来存储我们需要的视频。但是我们的游戏允许玩家装扮自己的角色,因此装扮必须在过场动画中。
Crashworks 2015年

21

在引擎中渲染过场动画的其他优点包括:

  • 与预渲染的视频不同,它可以扩展到硬件。一些较旧的游戏具有720p或更低的过场动画,在4k或更高分辨率的屏幕上看起来并不好。

  • 它更适合mod。如果您选择安装高分辨率纹理模块,或者只是想用看上去酷酷的巨狼替换您的Witcher的马,那么在预渲染的视频中将看不到这些修改。

  • 唇形同步更容易在引擎中处理。如今,嘴唇动画取决于音轨。这意味着配音演员不需要将其语音与角色嘴唇的动作同步。如果您需要将游戏从一种语言本地化为另一种语言,则您的配音演员只需要专注于自己的台词,而无需重新渲染场景。

  • 它更加灵活。无论您的角色是因受伤而勉强直立还是喝醉了,在引擎中渲染时的当前状态都可以比视频更准确地反映出来。

  • 环境被更准确地反映出来。也许您只是烧毁了整个森林,或者以某种方式设法避免了Aerith的死。好吧,预渲染的视频并不能解决所有可能的情况。


最后,所有这些都归结为这样一个事实,即在引擎中渲染的过场动画是动态的,因此提供了预渲染视频根本无法实现的灵活性。


16

以预渲染过场动画而闻名的游戏看起来比实际游戏要好得多,这些游戏是PlayStation 1时代的最终幻想游戏。例如,《最终幻想VII》的主角在过场动画中看起来像这样:

在此处输入图片说明

在实际游戏中像这样:

FF VII云游戏

这是什么问题?过场动画与实际游戏玩法之间的美学差异如此之大,以至于看起来几乎像是同一款游戏。过场动画和游戏玩法之间的突破是如此明显,它打断了沉浸感,并挑战了玩家的不信任度。

如今,游戏通过使用游戏引擎渲染过场动画来避免这种情况。这样,游戏的互动部分和非互动部分之间的切入就更加无缝了。

虽然这不是100%被遗弃的东西。例如,巫师3集成了一些预先渲染的CGI序列。介绍过场动画很著名,但在实际游戏中的某些关键过场动画中也有一些微妙的用法,只有注意视频压缩伪像才能注意到。通常通过在屏幕上没有主要角色的场景中执行此操作来解决由于角色自定义导致的一致性问题。


5
对我而言,与具有更好图形效果的预渲染视频相比,观看游戏中图形效果的特写更具沉浸感。尤其是因为即使在今天,脸部/头发也无法实时处理。
CodesInChaos

3
@CodesInChaos甚至实时渲染过场动画的游戏也经常在过场动画部分使用高质量的模型,纹理和面部动画(因为与玩家自由漫游整个世界相比,在这些场景中渲染预算更容易控制,他们可以在此处提供最详细的详细信息)。因此,即使在实时过场动画中,您也不必只看常规角色资产的放大视图。
DMGregory

3
我认为《生化危机2》很好地处理了这个问题,恕我直言。几乎所有过场动画都开始(或完全)在引擎中运行,并优雅地过渡到CGI。我认为,这与Myst对FMV的使用相当,除了极少数例外,几乎与1990年代的其他FMV游戏都差不多。当然,CGI在1996年比1992年的FMV更加令人印象深刻,所以我想我们更愿意忍受笨拙的流程来制作CGI过场动画。
user1103

2

预先渲染的过场动画的另一个问题是涵盖各种可能性,因为在当今的游戏中,您的行为会改变游戏中故事的进程。

因此,导致无数不同的结果组合,以及无数不同的预渲染过场动画。这有一些明显的局限性(数百GB,可能是TB)。

让游戏引擎实时渲染它,意味着您只需要发送包含参数的相关参数,该参数是玩家在该点之前采取的行动。然后,游戏引擎根据这些参数计算出可能的结果。

这样,仅从一个引擎即可添加所需的尽可能多的结果。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.