OpenGL中的渲染与3D动画软件之间的区别


16

使用OpenGL等,我可以“实时” 60 FPS渲染出一些令人惊叹的外观。但是,如果我尝试用Maya或3ds Max制作相同场景的视频,即使分辨率和FPS相同,渲染时间也要长得多。

为什么这两种类型的渲染要花相同的时间花费不同的时间?

注意:是的,我的确意识到3D动画软件可以产生比实时图像更高级的图像。但是对于这个问题,我指的是一个同样复杂的场景。


1
简短的答案是OpenGL采用了快捷方式。
user253751

Answers:


9

主要区别在于,假设使用OpenGL,在视频游戏中,您将拥有一个称为栅格化的过程,该过程主要用于确定您看到的场景的哪一部分。

它需要快速,以便我们可以实时体验。

因此,该算法执行了一些简单的步骤。

  • 检查场景的某个部分是否在我视锥中

    视锥剔除

  • 检查前面是否有东西,以后可能需要使用深度缓冲区进行渲染

    深度缓冲

  • 订购我们发现要绘制的对象

  • 通过将它们投影在屏幕上来绘制它们
  • 根据纹理/着色器/灯光/ 阴影对其进行着色

另一方面,渲染软件(Blender / Max / Maya / ...)最有可能使用某种光线跟踪

这需要更多的数学知识才能达到更高的真实感。它基本上以相同的方式工作:

  • 创建一个相机并在其前面创建一个图像平面
  • 通过每个像素发射一条光线(或多条采样光线)
  • 检查射线是否击中场景中的任何东西
  • 最接近的命中点是最终要在像素中绘制的命中点(如深度缓冲区)
  • 计算给定点的光 光线计算

....

我将在此处停止列出,因为这是光线追踪的起点。

现在,大多数raytracer不再只是检查是否击中了点,而是开始计算:

  • 表面穿透的光量
  • 多少光被反射
  • 从命中点向场景中投射新光线,直到可能撞到光源为止

有大量具有不同真实感的技术可用于计算场景中某个点的光线。

TL; DR 的要点是,光线追踪器在光线照射时大多会尝试在物理上保持准确,因此每个像素还有很多更多的计算要做(有时会发射数千条光线),而另一方面,游戏可以通过使用更简单的光线计算和大量的着色器技巧在屏幕上绘制更大的块,使其看起来逼真。


7

您正在将苹果与橙子进行比较

游戏就像建模应用程序中的视口。您可以使用视口进行渲染,您将获得相同的60fps速度。

没有理由无法从Maya或3DS Max等建模软件中获得非常出色的实时图形。与许多游戏相当的结果。就像游戏一样,它们具有视口着色器。还有一个视口渲染选项,可以将帧尽可能快地分块到磁盘上(我已经从Maya以30 fps的速度完成了全高清渲染)。您所要做的就是停止使用提供的软件raytracers。

虽然有一些区别。主要区别在于,作为用户,您没有像游戏开发人员那样优化内容(优化使用了本书中的所有技巧)。其次,因为您需要灵活性,所以动画基元可以在CPU上工作。在游戏中,人们有能力进行优化。总而言之,您要花钱才能没有一个编程团队在您旁边。

实际上,许多事情可能已经被预先计算了,所以它们并没有更快,而只是组织得更好。烘焙间接照明每天都会胜过非烘焙结果。

光线追踪器为什么变慢?

它们不是*,因为它很容易在光线跟踪器上做更多的工作。逐个特征,它们在计算周期上不会慢很多。例如,不需要光线追踪器投射辅助光线(在这种情况下,生命反射会消除几何形状,甚至不加载几何形状,实际上mental ray就是这样做的)。通常这样做是因为这样做很简单,这就是光线跟踪器的明显优势。在某些情况下,甚至可以将它们配置为在CPU上运行。它们只是针对不同的事物进行了优化:

  1. 将数据发送到磁盘,不仅是帧,还包括所有数据。会立即破坏大多数游戏速度的东西。

  2. 在一般硬件上工作。针对GPU进行某些优化后,GPU在某些情况下的运行速度将大大提高。但这并不适用于所有负载,实际上,Intel CPU的计算速度通常比GPU快。GPU只是大规模并行,而CPU不是。如果您可以留在GPU中并最大限度地减少转移并针对GPU架构进行优化,则该架构将为您赢得胜利。

因此,您需要支付灵活性和易用性。但是,没错,Maya和Max都患有极端的老年。因此它们可能更快。

TL; DR的区别主要是优化(阅读很多技巧)和可用的外部资源。

PS:有一个误解,认为这是因为它在物理上更正确。当然可以,但是光线跟踪器在本质上并不比您的普通游戏或任何其他计算更正确。实际上,许多游戏都使用非常好的模型,而许多建模者却没有。

*参见http://www.graphics.cornell.edu/~bjw/mca.pdf


2
对不起,但这是完全错误的。OpenGL和DirectX使用的近似值本质上比精确的光线追踪快。加速3D图形的整点是具有寻找算法,它的真实感和速度之间的平衡最实用的用法不够好:游戏,CAD等
伊米尔

2
@IMil OpenGL可用于光线追踪。它更快,因为它针对相关硬件进行了优化。但是Maya不必进行光线跟踪。Maya和Max可以像您的游戏一样使用openGL和directX。Mayas(和3ds)视口是opengl或directX(您的选择)。处理器在某些并行处理负载中速度较慢的事实是另一回事。答案是正确的。maya的标准设置比标准扫描线更真实。
joojaa 2015年

5

实时预览

在行业的VFX方面,如果您谈论的是实时视口预览而不是生产渲染,那么Maya和3DS Max通常也使用OpenGL(或可能使用DirectX-几乎相同)。

VFX动画软件和游戏之间的主要概念差异之一是它们可以做出的假设水平。例如,在VFX软件中,艺术家加载一个跨越数十万到数百万个多边形的无缝字符网格的情况并不少见。游戏往往会针对由简单优化的网格物体(每个网格数千个)组成的大型场景进行最优化。

生产渲染和路径追踪

VFX软件也将重点放在实时预览上,而不是实时模拟光线的生产渲染。实时预览通常只是对更高质量生产结果的“预览”。

游戏最近在逼近许多效果方面做得很出色,例如实时景深,柔和阴影,漫反射等,但它们属于重型逼近类别(例如:模糊的立方体贴图用于漫反射)反射,而不是实际模拟光线)。

内容

回到这个主题,VFX软件和游戏之间的内容假设完全不同。VFX软件的主要重点是允许创建任何可能的内容类型(至少这是理想的选择,尽管实际上它通常并不遥远)。游戏关注的内容要重得多(所有模型都应在数千个三角形的范围内,法线贴图应应用于虚假的细节,我们实际上不应有130亿个粒子,角色实际上并非由肌肉来动画钻机和张力图等)。

由于这些假设,游戏引擎通常可以更轻松地应用诸如截头锥体剔除之类的加速技术,从而使它们能够保持较高的交互式帧频。他们可以假设某些内容将是静态的,并且需要预先烘焙。鉴于内容创建的高度灵活性,VFX软件无法轻松做出这些假设。

游戏做得更好

这可能是一种有争议的观点,但是游戏行业比VFX软件要有利可图。他们单场游戏的预算可能高达数亿美元,而且他们有能力每隔几年就不断发布下一代引擎。他们的研发工作非常出色,并且始终有成百上千的游戏发行。

另一方面,VFX和CAD软件却远没有利润可观。研发通常是由从事学术研究的研究人员外包的,许多行业经常采用多年以前发布的技术,好像它是新事物一样。因此,即使来自AutoDesk之类的公司,VFX软件也往往不如最新的AAA游戏引擎那样“先进”。

他们也往往拥有更长的遗产。例如,Maya是一种已有17年历史的产品。它已经翻新了很多,但其核心架构仍然相同。这可能类似于尝试使用Quake 2并一直对其进行更新直至2015年。这可能是巨大的努力,但可能与Unreal Engine 4不符。

TL; DR

因此,无论如何,这只是该主题的这一方面。我无法确定您是在视口中还是在实时渲染中进行实时预览,因此我尝试涵盖两者。


这也是一个时间问题。即使您可以60 fps的速度渲染并获得可接受的结果,它也很少会对其进行优化。假设每帧需要3分钟,您有200帧要渲染。通过雇用着色器编写器并进行优化,您可能能够获得60 fps,但这至少需要一两天的时间。但是3分钟200帧仅需10个小时,因此可以节省成本。在实践中,以较低的价格购买更多的硬件,而不用担心太多。游戏根本无法采用这种方法。
joojaa 2015年

@joojaa虽然也有点复杂。即使对于一个经验丰富的着色器开发人员(收益较少),仅仅为Maya做一个非常好的实时着色器可能至少要花一年左右的时间,因为节点系统的灵活性主要是针对生产渲染。将这些通用着色器节点转换为捕获UE 4的效果范围的实时着色系统,将需要逆向工程的思维方式和一种新的GLSL / HLSL代码生成技术(例如元编程系统)。 ,例如
Dragon Energy

@joojaa UE 4的着色器引擎直接针对高度近似的PBR心态(迪士尼PBR着色器的很小一部分)。他们甚至为快速,实时的目的设计了材料系统,而不是从根本不像Maya的材料系统(为光线追踪而设计)开始。即使UE 4中最聪明的人在VP 2.0上工作,他们也不得不昼夜不停地工作长达数年之久,才能获得与不打算执行此类工作的设计相同的结果。
龙的能量

但是即使您在VFX应用程序中拥有该管道,也要花费一次成本,每个场景可能都需要进行额外的优化。例如,没有理由为什么Maya用户无法在UDK中渲染相同的着色器开发平台。
joojaa 2015年

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.