为什么Unreal 4引擎能轻易实时渲染出vray要花半天才能渲染出的场景？

d54892 · 发表于 2020-11-25 13:50

魔灵 · 发表于 2020-11-25 13:51

我来通过对比两张图片来答一下。下面两幅图，同样的场景素材，同样的光源，非常接近的材质模型，但用的是完全不同的渲染方法。

第一幅是我自己的渲染器用基于光线追踪的无偏全局光照算法渲染，第二幅是用虚幻引擎（版本4.7）的渲染引擎渲染。

首先说明一下，第一幅图片中椅子的扶手和桌子底部是塑料材质（漫反射加光滑镜面反射），而第二幅中是金属材质（粗糙镜面反射）。原因是UE4导出的时候没有把整个素材弄成一个材质了，我也懒得再编辑。然后桌上的雕塑第一幅是毛玻璃，第二幅是平滑玻璃。其余材质都一样了。

接下来点评一下两幅图中的不同之处。第一个最抓眼球的区别就是场景底部平面的镜面反射，两个都是用粗糙参数为0.25^2的GGX模型描述的粗糙镜面，上下图的差异很大。上图是完全基于对BRDF和光源采样的无偏结果，可当做参考，下图则是可以说暴露了虚幻引擎4对轻微的粗糙反射的一个缺陷。虚幻引擎4中的反射解决方案是屏幕空间反射（Screen Space Reflection，SSR）加环境贴图。对于非常平滑的表面，当它在场景中的反射刚好在屏幕上存在时，虚幻引擎4会使用SSR。当表面变的粗糙，或者反射部分在屏幕边缘时候，反射会变成SSR和环境贴图的加权和，直到对特别粗糙的表面完全变成使用环境贴图。（其实这里我只要再把粗糙度调高一点，SSR就完全没有了，不过那样就完全看不出反射了因为环境贴图的反射特别粗糙，不利于比较）所以下图中的结果可以说是一个平滑镜面反射和粗糙镜面反射的加权和，当然无法真正模拟出轻微的粗糙反射。（这个问题用最近的Stochastic Screen-Space Reflections可以得到一定的解决，不过很多时候不那么robust）

第二个比较细微的区别则是下图中桌椅黄色部分的镜面反射有信息丢失了。这个便是因为SSR算法本身无法处理反射物体在不在当前屏幕上的情况。这个Artifact其实在现在的游戏中也非常常见，相信很多人都注意到了。SSR另一个细微的错误则是反射中的镜面高光会是错误的，因为高光的计算取决于视线入射方向，直接从根据相机方向计算的屏幕上取是不对的。不过这个问题比前一个丢失信息的问题小多了，没人care。。

第三个差别是底部平面的高光区域在下图比上图分散很多，看起来下图底部的屏幕比上图更加粗糙。这个是由于两种完全不一样的Image Based Lighting的方法导致的。上图还是一切基于环境贴图的能量分布采样光源，虚幻引擎4则使用了Split-Sum，将渲染方程的光照部分和BRDF部分拆开分别积分，再对于两个积分的结果球积。具体可以看这个链接http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf

其中光照部分的积分又使用了Prefilter Cube Map的方法。再讲细一些，UE4的环境贴图是128x128x6的分辨率，7层MipMap。每一层的每一面都用1024个样本采样不同粗糙度的GGX去Filter。这里有几个产生误差的原因，第一是误差是采样GGX的入射光线永远是等于表面的法线方向，所以没办法模拟出上图那样在入射角和法线角夹角大的时候那种拉长的高光。另一个误差则是只采样了7个离散的粗糙度，并且不同的粗糙度使用的不同Mipmap，这样做对性能更有利，但是这种粗糙度和Mip层的映射完全是Epic的人“发明”出来的，完全不是基于物理。我自己试过同样的BRDF在UE4中做Image Based Lighting都会比真正的离线参考看起来粗糙许多。当然只要结果 Artists用着舒服，粗糙度看着有变化，也没有什么不好的。

第4个差别是下图中桌子下面的部分和上图比明显偏亮。这个误差则是因为环境贴图的遮挡信息只有在capture的那一点才是正确的，例如这里环境贴图是在桌子上面capture的，桌子下面的部分大部分入射光被桌子遮挡，应该会比较暗，这里则变成桌子下面接收到的光照和桌子上面一样，所以和上图比偏亮了。解决办法就是应该在桌子下面人工多capture一个单独的环境贴图。

除了这些区别，色调的不同，以及背景模糊度的不同，都是不同渲染系统的post processing参数以及其他工程性的小问题，就不细说了。

除了这些渲染本身的区别，实时渲染系统往往也需要更多的artists work才能hack出接近真实的画面，例如在场景不同的地方放置probes，提前烘焙光照贴图等。

最后，现在别说是用UE4做建筑可视化，就连做低成本动画电影的都有。毕竟快速的迭代可以降低很多的成本，也就有可能出现一些非Pixar那种一定要男女老少都能看才能保票房的题材的片子。

而且要不是我这样把UE4脱光了衣服拿出来比较，大家直接看着也不会觉得有任何问题。甚至我相信很多读这个答案的人盯着这两张图看不出差别的。搞图形的就是这样。。废了半天劲很可能是自娱自乐，真的搞的真实好看了，看得人也认为是理所当然。。

hxsdup1 · 发表于 2020-11-25 13:51

因为一般这类对比都是在用UE的长处去对比Vray的短处，毕竟营销成分还是很重的。

从我的经验来说，在中小尺寸比如4k或者以下分辨率，计算漫反射为主导的场景，比如一堆石头，UE的确是很有优势的。但如果输出尺寸是6k以上，或者场景中以反射和折射为主导，比如一堆玻璃球，那UE就很糟糕了。

另外，这类对比的呈现渠道一般是手机或者普通显示器，vray在细节上的优势也体现不出来。同时也没有考虑到UE在美术素材准备期间消耗的大量工时，而只是在单纯的对比每个画面的计算速度，显然不够公平啊。

glcat · 发表于 2020-11-25 13:52

来补充些内容，让这个事情说得更明白一些：

先上视频：

UE4场景练习—在线播放—优酷网，视频高清在线观看
http://v.youku.com/v_show/id_XMTM0OTg3NDIyMA==.html

我和余德杰都是建筑学的，爱好CG，做这件事情，就是想学一下UE4，视频什么的都是学习过程的副产品，学了半天总得做个小成果展示一下啊。

楼下说软文的先生 @haisenberg ，你确实是误会了，不过也不怪你，因为这个问题看起来确实很像软文！（笑）为啥咧？因为这是建筑系的同学问的，搞引擎和游戏的专业同学不会有这样的误解。

要知道建筑学这边的学生一般都是拿Vray之类的渲效果图的，也没人教，都要很苦逼的自己摸索，突然看见这么好的实时效果，自然会冒出这样的困惑。

所以，要认认真真的的回答这个问题的话，还要按知乎的规矩来：先问是不是，再问为什么。

不存在题主所说的情况：UE4并不能轻易实时渲染出写实场景。

想要一个好的UE场景，前期需要大量的优化，模型的优化，贴图的优化，然后还需要光影烘培“Build”的时间，而这个时间，就类似于Vray在渲图的时间。参考这个问题下的几个专业人士的回答，拿Vray渲染器和UE比其实是不公平的。

但是UE的间接光线不像Vray渲染的精度那么高，在能容忍的粗糙范围内，小场景的Build的时间也不需要太长。

以我们这个场景为例，因为模型用的是现成的Evermotion高精度模型，未经优化，最终整个小沙盒的Build时间是2小时左右。配置是：i7 5820k。如果模型优化得好，Build时间会大大降低，但是优化的时间要数倍于为Build节省的时间，但是别人运行起我们这个场景来就会更流畅。我们要是把周边的墙断开成四个小面的话，墙的光影贴图面积就不用那么大了，墙上的光影精度会大大提升，Build时间也会下降。

你发现了吗？就像等价交换一样，一切效果都要代价，效果好则时间肯定相应增加，无论你是离线还是实时渲染。处处要取舍。

我个人一直主张在学习设计的过程中把建筑的可视化技术前置，结合到方案推敲过程中，而不是方案做完了画张效果图交差，那样对建筑学习没啥意义。我们看中的是实时渲染沙盒的自由度，以及模型搭建出来以后，推敲材料的方便性。

所以这里提醒各位建筑系同学，好工具要用对了地方，不要看视频效果好就拿UE做效果图，最后很可能吃力不讨好。这事情不是这么个玩法的。

当然了，如果是专业做效果图的公司，自己优化好大量的模型库，那做起效果图来效率也是非常高的。

Lumion就是想做这方面的尝试，我之前搞错了，我之前以为是ue3，经评论提醒，Lumion是基于quest3d引擎开发的。

但是之前的Lumion效果还是有点假，不知这次的新Lumion怎么样，有没有突“假与真”的临界点。

现在UE4效果更上一层楼了，如果有人用UE4做一个供建筑设计专业使用的软件，那确实会很有助于空间材质效果的推敲。

下面简单说说光影烘培技术的思路。

实时引擎的光影烘焙利用的一个事实就是漫反射物体的光照和光线反弹是“摄像机无关的”。

比如下面这个简单的场景，立方体、球体、光源的空间位置一旦敲定，每个点的着色就不会随着观察者位置的移动而改变了。说白了就是，我摄影师扛着相机围着你乱跑，模特脸上的颜色不会跟着变来变去的。

如果场景光照条件固定，那么这些光影信息就没必要参与实时计算了，只需要预先计算出来，在UE4里叫“Build”。然后把这些光线的明暗着色“烘焙”到物体表面就好了。

所以物体表面的贴图着色就变成这样了：

如是制造了光影着色的错觉。

所以虽然叫实时渲染，但是很多时候并不是“实时”计算的，而是预先计算的。

UE4里的lightmass还不简单的是一个光影贴图，而是一个立体的阴影区域，Build好以后，只要物体挪到了影子里，也会变黑。很棒的技术。

刚才说了光照是“摄像机无关”，反射效果就是“摄像机相关”的：

要补一句，这里的反射是狭义的像金属之类物体的光亮的反射，不包括漫反射，昨天有位同学问我漫反射也是反射啊，把我提醒了。

一旦涉及反射折射等效果的着色，那么就和摄像机的位置关系很大了（不同角度反射到的内容自然是一直在变），这种东西就要靠实时的显卡计算，但是在实时渲染中，这里面trick很多，能满足视觉效果，但是不科学。

科学的还是maxwell那种物理模拟计算，需要离线渲染，需要很多时间。

知乎图形学大神太多，我这个压力还是很大的。

zhangyan_cg · 发表于 2020-11-25 13:52

算是自己开发实时渲染引擎，所以想关于这个问题谈论下自己的看法。
我觉得楼主的问题出现了三个很大的误区，有必要纠正一下。
第一，从光影的效果来说，Unreal并非是一个全实时计算的引擎，而是实时计算+预渲染。游戏引擎中为了呈现出以假乱真的效果，很多时候都会使用预渲染的技术，所谓预渲染的技术，其实就是把一些复杂的中间计算结果缓存在贴图之类的存储结构里。这样的技术非常常见，大部分的核心思想是算法里面的空间换时间的策略，或者是简化问题的模型，减小计算规模，所以现在单机游戏越来越大，很大一部分资源是被这些东西占用了。我简单列举一些常见的为了逼真效果而做的预渲染：
light map，这个东西应该是最广泛使用也最早使用的东西了，简单的说就是把光强度在整个场景中的分布用贴图存储下来，配合第二UV，在真正实时计算光照的时候就省去了计算光强这部分的计算量；对于一些复杂形状的光源，在很难对它的光强在任一点的积分求数值解或者计算量过大的情况下，一般这类光强分布会被缓存在一张贴图上，叫法可能各不相同，或者是environment map，或者是image based lighting，或者是IES light，但是这类东西我觉得本质上是一样的东西，都是光强分布函数的离散化存储，计算是离线的。在实际应用中，比如局部的反射策略可能是environment map + SSR（屏幕空间反射），比如为了绘制天空的色彩，会把大气散射系数，介质浓度之类的参数引入，预计算一个参数索引的离散数组用来模拟实时的天气效果（阴晴或者早晚），复杂形状的光源可以考虑用光域网（IES LIGHT），整个场景中的复合的多光源的光强叠加分布模拟可以考虑light probe的线性组合，这类预计算往往都有一个特性，就是光源位置，受光物体的位置之类的往往是不能动的，这也就间接说明了Unreal其实不是全实时渲染的。当然有些预渲染方案能做到和光源位置之类的无关，比如说球谐系数这样的预计算方案就不要求光源位置固定，但是即使如此它还是会有一些明确的参数固定限制，比如光源数目一定是固定的。
第二，从光影效果上来说，Unreal的效果绝对是不如Vray之类的好的，之所以会有Unreal看起来效果和Vray一样的错觉，是因为在很多领域都会存在类似边际效应。也就是说，并不是我花两个小时渲染一张图，得到的效果就一定比你花一个小时渲染出来的图的效果好一倍。这其实是个很简单的道理，当效果好到一定程度的时候，想要细微的提高也要大量的计算量，就拿这两年比较流行的GI问题来讲，理论上讲间接光照是可以无限递归下去的，但实际上间接光照经过三到四次的反射，它对一个物体表面的点的颜色的贡献就微乎其微了，所以当你使用光线追踪技术来渲染一张图，递归次数调成10和调成4在其他参数不变的情况下可能效果也不会有肉眼明显可见的区别。而这两年流行的许多新的实时GI算法，就是相当于处理了一个多项式的高阶部分的近似而舍弃了低阶部分，同时它也一定程度上降低了问题规模。譬如Unreal用到的voxel cone tracing，按我的理解实际上就是蒙特卡洛方法的一个近似版本，这个近似版本能够很好的模拟出间接光照的主要贡献，至于那些次要的贡献，像楼主这样可能美术专业出身的童鞋也不一定看得出，何况是一般的游戏玩家在眼花缭乱的场景里。更早一些的时候，还有SSVO用来模拟间接光照造成的局部明暗，或者是有light shaft来模拟介质的散射效果，更早以前的时候的天空盒来模拟大气。所以任何引擎肯定都会在单位性能对画面的提升效果上力求性价比最高。
第三，Unreal终归是一个游戏引擎，它的设计目的不单单是为了渲染画面如何优秀，更多的是针对游戏的一些特殊功能的开发和应用，以及如何简化游戏开发的工作流，而Vray这类是专为渲染而生的，它们之间或许在渲染方面有交集，但是并不存在互相替代的关系，甚至可以说不太相干。

看到回答中有人提到PBR的问题，如果广义的来说，像Unreal这类游戏引擎它往往不会保证一个光影效果在物理上是否正确或者是基于物理，所以在这种情况下确实可以有很多trick来使实际效果看起来像是那么回事儿（即使物理上是错误的），同时性能开销又比基于物理的方法低很多。而离线渲染的引擎可能在这方面会显得更严谨或者学究一点。但是如果是以这两年游戏引擎常提到的狭义地Physical based rendering的概念来说，所谓的基于物理渲染只是对以前较为简单的BRDF模型加入了微表面的概念而已，因此如果是狭义上的PBR，其实和楼主的问题没什么关系，也和Unreal为什么比Vray快很多没什么关系。
以上是就我懂的来简单称述，如有不对的请指正。

灵之舞 · 发表于 2020-11-25 13:53

baking过lightmap了呗，背后花的时间也未必就比vray花的时间少了。
游戏渲染和动画渲染是一条从两头挖掘的隧道，会越来越相像。

游戏渲染的光影效果如果是要实现GI,基本都是有前期baking的工作，做完之后，在posteffect上叠加了ssao ,甚至ssdo等等的效果上去，以尽量绚丽，但是减少渲染工作量的方式，实现实时渲染。

当然题主用vray比较，其实不公平，vray还是太老了，gpu对渲染的加速效果没被考虑进去，用过octane和unreal比较，好像更能体会两个领域的不同技术发展。 octane即使牺牲一部分质量，效果也是跟接近物理真实的光照感觉。
当然unreal也不错，lightmass还是效果相当好的。

但是用unreal4做效果图是个脑残行为，我私下跟朋友解释过多次，游戏引擎是庞大的，渲染模块是非常小的部分，如果用于效果图，那所有的模型导入材质简化等等的工作，就没有必要，而这部分工作其实是巨大的工作量，（我还没跟你算投入和产出呢，不划算），如果真要做，就做交互式的程序，才有点用处，（其实还是没卵用，客户压根不想做这种操作，除非你提供功能性进去，但是光擅长效果图的制作者，哪里顾得上功能）。

Lumion其实也是个脑残玩意，对建筑效果图的需求来说，需要的是一个渲染神速的渲染器就好了，Octane做渲染，redshift做动画渲染是大趋势，只不过国内这方面技术的讨论非常落后，大家还以为lumion什么的还多新鲜，还以为cryengine的渲染比unreal强， no no no, 那些早老土了:D

无敌甩葱歌 · 发表于 2020-11-25 13:53

物理渲染必不可少的两部分：物理正确性，物体可见性。其中物理正确性在于使用拟合公式来模拟光线运动的规律，表现出漫反射，高光反射等等。而可见性则是需要知道光线发出的位置与反射光线的位置。
基于物理渲染，即Physically-based rendering，是在光栅化中使用拟合公式进行光线模拟的，因此其物理正确性与离线渲染并无太大区别。然而在可见性上，实时渲染要比离线渲染差许多。
比如这里放一张实时渲染中截的图（UE渲染用的不熟练就先用U3D代替了……）：
这张图表面看起来貌似挺“真实”的，然而仔细观察会发现其漏洞百出，实在谈不上以假乱真。首先是AO，在这张图的渲染中我们使用了Ground Truth Ambient Occlusion进行间接光与环境光的遮蔽，GTAO是使用屏幕空间信息来制作的，也就是每个像素点的深度，色彩，高光度，法线等信息，很显然屏幕像素的“可见性”是明显不足的，因此可以看到，在左下角的灯柱，沙发底部，给人感觉明显的“不正确”感。纵使GTAO是现在光栅化渲染中非常先进的算法，也很难达到离线渲染的正确性。
然后是反射，反射是对可见性表现最直观的部分。这张图中的反射使用了屏幕空间反射，因此屏幕外的物体就没有办法被反射到，很明显这又是一个“可见性”的问题。因此实时渲染中的反射，常以“看着差不多就行”作为标准。
间接光也可以被认为是反射的一部分，实时渲染中，由于光栅化像素周围的环境信息不可见，很难制作实时的间接光，因此这张图中的间接光实际上都是在制作时提前烘焙好的，这点可以认为其本身就是离线渲染。
这么看来，Physically Based Rendering毕竟只是Based，在渲染可见性上是无法与离线渲染相媲美的。

霸气的昵称 · 发表于 2020-11-25 13:53

渲染器如vray等和游戏引擎如虚幻4等在渲染原理上有什么不同？为何建筑渲染不用又快又好的游戏引擎渲染？ - 三维渲染
这个问题其实已经有人问过了。
我觉得之所以游戏引擎不能替代vray之类的渲染引擎，主要得问题在于对材质上可能性的差距。
既然是游戏引擎，为了提高载入速度一定会采用大量的预渲染。换句话说，游戏引擎看起来能轻易实现常见材质的渲染效果，是因为这些材质的参数被预先设定在了程序里面，在你选定组件的时候，它在画面上的表现直接从参数表里拖出来就是了。所以类似的lumion这种原理类似的渲染器也是一样，库里选一颗树，拖进去画面里就出现一颗树，非常快。
但是
如果我要改变这个树的颜色呢？改变树皮的纹理呢？改变树叶的透明度呢？增加叶脉的细节呢？
如果每一个变化我都要在数据库里做一个预设，那么这个渲染器的体积就会不可避免地庞大下去，最后根本没办法载入了，因为没有电脑的硬盘和内存能够储存这么多的数据。所以这种时候还是得需要vray这样的渲染引擎，尽管慢，但它可以让你创作现实中任何（当然在引擎的理论范围内）有的或者没有的效果。

综上，如果你全部使用成熟的已知的材料，那么游戏引擎类似的渲染器有明显的速度优势。其实很多建筑表现已经开始采用了。和revit等等bim软件对接仅仅是时间问题，到时候建材厂家在云端上传材料参数，bim软件直接调用，即时渲染，画面太美不敢看。
但是如果你希望以渲染图来推敲不同材质导致的氛围变化，自然还是得需要vray这样的渲染器。

罗明工作 · 发表于 2020-11-25 13:54

UE4 能渲染面对面的镜子么？

u3d8 · 发表于 2020-11-25 13:54

严格地说，引擎的效果图输出在绝对质量让上没办法跟传统渲染器对比，只不过好在最终客户那里不追求绝对的精度，，只是感觉对了就可以了，而且国内客户龟毛得多，不改个几十次肯定不甘心。

为了提升引擎的处理效率，GPU的功劳很大，这跟传统的只吃CPU的vray效率高很多，然后是PBR材质的广泛使用。在你看得到的地方展示细节，你看不到的地方就省资源。多方面的结合，才有看起来初步多好的效果图。

很多时候多倍的时间消耗带来的素质提醒并没有时间这么大。简单说，你用三个小时渲染的图，UE4里面一个小时出来的图不一定只是你的三分之一的画面质感。对于最终用户来说，对于绝对精确的追求者很少，大部分人只是看结构，色调，搭配感觉舒服了就可以了。所以以引擎为代表的GPU渲染模式才逐渐的被人广泛接受，想当年Vray之前的Brazil渲染器，慢的令人发指，还有一个叫lightscape的（拼写好像不一定正确）都以追求物理级别反射真实性著称。但是随着时代进步，硬件效率提升，人们更加注意到在画面之外的重要性，所以效率成了很重要的部分

		自动登录	找回密码
密码			立即注册

为什么Unreal 4引擎能轻易实时渲染出vray要花半天才能渲染出的场景？

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源