精华内容
下载资源
问答
  • 渲染技术入门经典书籍,美式写作风格,干货满满,适用于多种制作工具。
  • 3dsmax photoshop 影视游戏贴图渲染技术全解析 课程资源 《3ds Max/Photoshop影视游戏贴图渲染技术全解析》详细讲解用3ds Max和Photoshop等软件进行影视、游戏贴图制作的完整流程,全面展示道具、角色等各类型贴图...
  • DirectX实时渲染技术详解[(美)Kelly.Dempski扫描版],含源码,PDF含目录索引,点击目录直达章节。
  • 《DirectX实时渲染技术详解》(Kelly Dempski)【 重庆大学出版社】(1)
  • 3D渲染技术 探索

    千次阅读 2019-10-20 11:37:21
    目录 ...1.三维渲染 软硬件的历史 2.图形学的挑战与对策-真实感 DOF/Texture/Dynamic Shadow/Texture Mapping/Bloom/Flame,Fog/GI-3S/Volumetric Lighting/GI-RayTracing etc. 3.图形学的未来发展

    本人同意他人对我的文章引用,但请在引用时注明出处,谢谢.作者:蒋志强

    多年未更新技术BLOG,这次系统的谈一下3D渲染技术

    目录

    1.三维渲染 软硬件的历史

    2.图形学的挑战与对策-真实感

      DOF/Texture/Dynamic Shadow/Texture Mapping/Bloom/Flame,Fog/GI-3S/Volumetric Lighting/GI-RayTracing etc.

    3.图形学的未来发展


    1.三维渲染 软硬件的历史

    80年代3D显卡还没有出现(已经有2D显卡),但图形学已经发展很久了,人们已经在计算机如何可视化三维空间物体方面 有了完备的理论;线性代数,几乎就是为三维图形学 私人定制的表达和计算基础。相对于当时的PC较弱硬件的能力,三维渲染还停留在服务器计算 影视作品中;(像现在游戏界很火的光线追踪等技术,在当时就已经有很深入的研究了)

    这样的情况直到90年代初期,3DFX,MATROX,S3,Nvidia,SiS,ATI等公司的努力下,专门针对3D图形学计算的3D硬件显卡出现,并推动了三维渲染的巨大发展,让三维渲染的应用推向了普及;

    是三维渲染发展有两个常态:

    1. 理论等待工程(软件&硬件)发展

    2. 效率是关键

    硬件上

    通过线性代数描述三维的物体,需要X,Y,Z三个量,线性代数上要线性独立需要第4个维度,实际上三维的基础计算单元是4维向量,所以当时显卡的物理硬件计算单元是4元向量(现在也是);

    三维表达的大小/位置不在乎绝对值,而取决于相对值,浮点更合适三维计算,所以显卡芯片的浮点计算能力强于定点(现在也是);

    为了快,大量顶点传入进入显卡后,线性代数的几何变换计算相互独立并行进行,直至显示到屏幕,数据不再出显卡,所以在硬件架构上循环/判断是GPU的弱项,数据CPU/GPU间传递效率是弱项(现在也是);

     

    软件上

    硬件上的变革,需要软件的协同以便高效的控制底层,Glide(3DFX),DirectX(MS),OpenGL(Khronos)成为了主流3D接口;

     

    它们专门为编写软件三维渲染而生,天然的面向渲染硬件管线;(由于3DFX后来垮掉了,DX/GL成了现在软件标准)

    DX/GL的上层描述实际上是面向硬件的描述,以现代GL为例(DX是一样的),软件层描述的简化硬件管线如下

    类似于工厂加工的流水线结构,数据一旦进入,一路向前 直到显示,相应3D处理运行在硬件指令级别;

    (黄色是硬件级计算单元:着色器)

    插播GPGPU广告

    2007年前后发展起来的GPGPU应用,本质上是搭渲染链路GPU的顺风车。图中我圈红的Vertex/Fragment着色器是最古老的着色器,在GPU最早阶段就存在。Vertex的X/Y/Z/W是4元向量计算,Fragment的R/G/B/A也是4元像素计算,很多的矩阵操作也很类似,所以NVIDIA在与MS合作第一代XBOX时,将两类着色器在硬件层统一起来,相当程度上可以互换,称为统一着色器

    统一着色器克服了某些应用下顶点计算单元不够而像素计算单元空闲,或者顶点计算单元空闲而像素计算单元不够的窘境。

     

    而显卡中的矩阵计算 A*B ,

    其中包含了加法/乘法,而且计算的元素是浮点数,乘以一个大于0的小于1的数,等效于除法,加上一个负数,等效于减法;

    实际上这基于浮点运算的矩阵乘法已经是在硬件级别具备了加/减/乘/除的基本运算能力,所有更高阶的计算都可以拆解为加减乘除;所以渲染链路中的着色器在硬件级别具备通用计算的全部能力

    由于在XBOX上非常成功,PC端的GPU架构也做了这样的改变,这在硬件层面扫清了GPGPU的最后一个困难,所以才有了CUDA/OpenCL的发展。对于存做GPGPU的朋友,往往简化理解GPU内部是compute unit或是CUDA core,实际上后面是各类渲染链路中的着色器;

    我们需要清楚:

    1. 凡是渲染管线GPU面临的问题,GPGPU都逃不掉;(当你当顺风车时,你也需要接受别人车上的具体问题)

    2. 3D渲染方面,若能做成渲染管线的方式,效率胜过GPGPU;(GPU硬件毕竟是为3D渲染“私人定制”的)

    建议:做3D渲染,首先考虑做进渲染管线,太难做进渲染管线的部分,以GPGPU方式配合渲染管线;

    广告结束

     


    2.图形学的挑战与对策-真实感

    什么是真实感?

    一种主观感觉 还是 客观量化的成分。什么因素让我们觉得计算机渲染的结果 真实 或 不真实?

    我的理解是:人对可见光的各种物理规律的主观经验印像。它与两个方面相关

    1. 它与外界客观物理规律相关;

    2. 它与人的生理结构相关;

    下面是两幅计算机渲染场景(左:极品飞车2渲染截图;右:CryEngine渲染截图)

       

    我如果说左图不真实,右图很真实,大部分朋友应该会同意;造成这样的感受

    1.物理相关:

    左图中:白车后的尾气与常识印象不符;汽车表面反射与印象不符;地面图像成方块状与印象不符;雨水形态与印象不符

    周边树木形态和光照与印象不符;环境中光照生硬与印象不符等等... ...

    2.生理相关:

    左图中:运动中物体无运动的模糊速度感,与印象不符;远处物体变淡,而不是变模糊,与印象不符;天空中没有耀眼的感觉,与印象不符;等等... ...

    人眼一扫,只需要不到半秒,大脑就能发现左图中如此多的与物理规律和生理感知的问题,让我们不仅惊叹,这些问题也成为了图形学发展中的挑战;

    下面来看看历史上图形学的工程师们的努力和解决方案

     

    景深DOF

         

    人的眼睛,摄像机的镜头 本质上 是凸透镜,当我们调整眼球晶状体形态 或 相机镜头焦距时,能把相应距离的物体清晰的落在视网膜 或者 摄像机的CCD上,而偏离这个距离的物体将逐渐模糊,这就是景深Depth of Field,虚化是DOF的典型效果;

    在3D渲染中,常见方式是把渲染物体先计算其成像距离,根据距离远近设置模糊的程度,以近似的模拟DOF;

     

    左边是最终效果,右边是深度图,根据深度图分批多次渲染,远离焦区的物体逐渐加强模糊,然后按先远后近的的次序合并(以确保遮挡关系正确)。

    这是近似模拟,我自己也尝试不用深度图模糊,而从人眼聚焦原理上来实现,如下图(左图是不考虑人眼透镜效应,右图是根据人眼聚焦成像)

      

     

    动态阴影

    有光照就会有阴影,特别是渲染场景中有运动物体或运动光源,总会造成阴影的动态变化于交互,这就是动态阴影;

    是否考虑动态阴影的差别如下

    一般来说,动态阴影需要在渲染管线里走两次或多次;常规思路有shadow map, shadow volume等等;

    我以shadow map为例解释,如图所示渲染一些在单个点光源下的小球;

      

    首先从光源方向进行成像,获得一幅渲染结果,只取渲染结果中物体距离光源的远近,留做后续渲染备用

    变换至观察位置后,进行第二轮常规渲染,判断观察面中的任意点距离光源的位置,是否比之前的距离光源的远近大,从而进行不同策略的渲染;

    我自己也写程序试了试,效果如下(我很懒,第二轮渲染时,什么酷的效果都没做)

     

    纹理贴图

    纯色的物体与真实情况差距很大,工程师们创造了纹理的概念去表达细节。最简单的情况,纹理贴图是贴在几何多边形上映射位图,用以伪造实际的物品。我写了程序,用多边形画个球,给些基本光照,看上去如下左图。看上去也不知道是什么东西,我打算伪造成地球,所以找张地球的二维投影位图(如下图中间),把它映射到到相应球面的点上,效果如下图右侧,似乎像个地球仪了

    PS:感兴趣的朋友,可以看看https://blog.csdn.net/gamer_gerald/article/details/1762064 (太古老,仅供概念了解一下)

               

    这样做问题很多,虽然它多了纹理像素信息,但它是平的,没有影响到光照。所以工程师们创造了新的纹理技术 叫做

    Bumpping Texture Map.让映射到的表面结构,看上去发生了变化。Bumpping Map第一种思路,是Normal Map,多创造一层纹理,叫做NormalMap,它存储法向量调整信息一种。对于物体上的点,先计算基本法向量,再用NormalMap调整,再计算光照。让物体的光照效果受到影响,让人感觉表面似乎凹凸不平,反应出更多细节。

      

    Normal Map以一张纹理的代价,换来了三角形个数的大幅减少的同时,让其达到高三角形模型的细腻效果。Normal Map一般是通过专业建模软件生成,先做一个低三角形的模型,再做一个多三角形的模型,两者几何法向量做差得到Normap Map以纹理格式存储(R/G/B分量表达X/Y/Z的几何法向量),渲染时使用低三角形模型,配合Normal Map对低模的法向量调整,以达到少花钱(资源)多办事(近似高模的细节信息)。

    但Normap Map只是操纵了光线的法向量,没有改变实际几何形态和纹理位置,所以只可远观,近看漏洞百出,特别是平行与三角形平面时,几何关系的错误暴露明显。如下图的Normal Map,其凸出的砖块的纹理位置是不变的。

    如下图,由于凹凸的关系,观察者看到的应该是a点,但实际情况下看到的是b点,解决方式是在这个位置把a处的纹理坐标调整到b处,修正其假像,如何计算修正值,所以工程师们引入了高度图,创造了Parallax Map

       

    下图是Parallax Map的效果

    Parallax Map并没有增加顶点/三角形个数,但计算量已经比较大了,需要逐像素计算其纹理偏移量,Fragment着色器压力已经较大,寻找合适偏移位置往往绕不开循环查找,GPU痛恨while语句,反复纹理采样,访问显存,GPU痛恨访问显存,工程师需要好好衡量。

    Parallax Map也有一些问题,比如几何上还是没有真正创造出更复杂的细节结构,比如光照下阴影的问题,工程师们总是喜欢挑战,又创造出带自阴影的Relief Map(浮雕贴图)技术,双深度Relif Map技术等。但后续这些技术,往往都伴随一些side effect或者计算过于复杂了。(感觉成本比做高三角形模型的成本还高)

     

    补充

    以上这些方式基本上都是为了在减少三角形个数的情况下,还尽力模拟其效果。另一类思路是分形,在减少三角形输入个数的情况下,在显卡内部链路中细分出更多的三角形,这也就是细分控制,细分评估着色器的专长,本质上就是做分形,如下图

    左图:分形前,右图:分形后

     

    Light Baking 光照烘培

    光照的计算成本是很高的,特别是高质量的光照,所以图形学的工程师创造了Light Baking的思路。先由3DS MAX, Maya,Unreal,Unity等工具进行离线计算,然后将计算结果生成场景的纹理贴图,大部分固定光源的效果由纹理贴图表现;

    如下图左(Unity离线烘培光照),下图右(Maya离线烘培)

      

    在实际渲染中,基础光照全由离线烘培提供,运动人物,光源再进行实时计算;由于离线烘培不占用实时资源,我们有可能使用高复杂度,高度物理准确的光照模型,例如复杂材质情况下的光线追踪,如下图(UnReal的Ray Tracing级别离线烘培)

    3D游戏中一般是烘培基本场景,如下图

     

    AO环境遮挡

    Ambient Occlusion是另一种讨巧的光照技术思路,基本思路是计算:物体的直接/间接光照被周边几何结构的遮挡

    可以实时计算,也可以提前烘培至纹理。它是一种很便宜的GI方式,在合适的情况下效果不错,价格便宜。

    如下示意,AO值是在空间上做积分,计算特定点有多少光线被遮挡。

    如下图(左:原始渲染NO AO, 中:AO计算图,右:原始渲染+AO)

    AO可以离线做成纹理,也可以在屏幕空间实时计算(SSAO,最早由CryTek公司创造),是一种性价比 比较高的

    GI间接光照的解决方案;

     

    Bloom晕光

    当我们的眼睛观察较强的光照物体时,由于光照过强在视网膜成像位置周边有较强的散射,会感觉晕开,亮瞎了我的狗眼。

    这就是晕光效果;

    常规的处理思路是,再进行一轮渲染,只提取较高亮度的区域(如果你需要加强效果,可以把这一部分亮度更加强一些)

    多该内容离线BLUR

    screen_bp_5x5.jpg

    然后于原渲染图混合;

     

    烟雾及火焰

    烟雾/火焰 是3D渲染的短板,因为3D显卡内部的基础处理元素是顶点,三角形,平面等离散的几何单元,而烟雾是一堆?一坨?

    所以烟雾很不好表达,图形学的兄弟们创造出了点精灵(Point Sprite),在现代显卡的硬件都能支持。它只是一个点,抽象单个点无法映射二维纹理,点精灵的妙处就是它可以有尺寸大小,所以可以给它进行二维纹理映射,并且它始终面向视线;把一大堆点精灵聚集在一起,就能创造出烟雾,火焰,粒子等效果,下图就是众多的点精灵呈现的云雾;

    点精灵呈现的火焰

    其实没有点精灵也能做,但Point Sprite专为粒子系统而生,传1个点顶4四个用,而且始终朝向摄像机,是效率最高的。研究图形学的朋友一定还知道,Geometry Shader也能做类似的事情,传1个点给它,它可以创造N个点;

    下面是我自己写了个小程序,只输入了4个顶点,本来只能做1个四边形,但却绘制了15个四边形,多出来的四边形都是在管线内部创造出来的。

    建议做烟雾,火焰还是用Point Sprit,因为它是仍是效率之王。在Geeks3D上有朋友做过效率PK,结果如下

     

    更真实的光照SSS

    前面提到的光照阴影,其实有不少瑕疵,例如光线只有照到或没有照到的明暗,实际上很多物体是半透明的,阴影不是实的,有的物体挡住光后,光还能通过它,只是变弱变暗,同时变弱的光还会反射透回来,同时光在传播过程中还会发生各种变化,这属于GI(Global illumination)中高大上的SSS光照效果(Sub Surface Scattering)的范畴。

    下面这幅stanford dragon的渲染就是这样的例子

    我们注意到这个dragon没有绝对生硬的黑色阴影,这更符合我们对光的主观经验印象,所以我们感觉更真实

    类似的效果是shadow map,shadow volume等都做不到的,所以我们需要创造新的思路。自然界中本就不存在阴影,所谓阴影不过是那个地方的光相对较弱。

    所以我以此为思路,写了个程序,找了个CT的人头数据,渲染效果如下

    效果已进步不少,但比dragon差些(主要是我程序里只处理了单色而不是彩色的);

    如下左图(照片)是真实的光照效果,我自己把前面做DOF的数据拿来,写了GI SSS的程序,渲染效果如下右图

      

    目前,医疗彩超3D成像暂时停留在这个层面,下图是商用超声3D成像中的渲染效果;

    在3D影视特效的渲染中,为了达到真实感,在渲染人物皮肤时运用GI中的SSS只是初级要求;

    (其实全局的Ray Tracing,也是基本标配,我们后面会提到)

     

    Volumetric Lighting 体光照

    光照会产生体散射的效果,如下图所示。

    本质上,这是由于大气环境中,存在很多小的灰尘颗粒,这些颗粒产生散射。我自己写了程序模拟,做得不好,但原理是相同的,如下图所示:

    商业级渲染引擎中(如UnReal/Unity/Crysis Engine/etc...)帮大家都做完了,打个勾就行了。

    PS: 目前像UnReal, Unity等引擎都已开源,是个宏大的图形学宝库,可以好好学习。

     

    光线追踪 Ray Tracing

    光线追踪是图形学里很老的概念,属于Global illumination范畴中经典的解决方案,它研究光线直接照射到物体上后,间接反射到其它物体上,产生间接光照,间接光照又产生间接光照,如此反复循环。理论上,它是无限的递归,计算复杂度是 无穷大。它向实际物理光照迈进了一步(实际物理光照还有衍射效应,菲尼尔现象,波动性,色散等),所以能产生较强的真实感,下图是典型的光线追踪效果

    注意白光照到墙壁后产生二次反射,让立方体物体带上颜色,立方体再次反射,其倒影也带有颜色,光滑的球体的镜面反射又映射出房间的影子。对间接光照,需要其颜色,强度,方向等特性随着与不同的反射面交换持续的发生变化,营造出很高的真实感。下图是Cry Engine的RAY TRACING示例

    良好的Ray Tracing在GI体系中扮演着关键角色,因为它实现之前有提到的众多的光学特性,One Solution For Many Effects !吃一片,顶多片。例如景深DOF,漫/镜面反射,环境光融入,软阴影,运动模糊等都可以通过RT来实现。

    Soft Shadow

    Reflection

    DOF

    Motion Blur

    目前的工程做法是进行各种不同的蒙地卡罗积分,有的是从视点平面做积分,有的是从发光源做积分,有的积分域增加了时间维度,有的考虑更多的积分域,大家的共同挑战是计算量极大,在硬件上底层渲染流水线不支持这样的计算,导致很慢,都是离线计算完成。

    在这个基础问题上Nvidia勇敢的迈出重要了一步,在硬件上重新设计计算内核,新的RTX显卡最重要的革命之一就是增加了专门RT内核(另外一个是AI加入专门针对Deep Learing的Tensor内核),从架构上打下了让光线追踪的实时的基础。

    (真不是打广告,这的确对图形学是很基础很重要的进步)

    硬件级别的改变,让Real Time Ray Tracing商业化推开,如战地5等游戏已经支持实时光线追踪

    我们需要特别关注,因为2018年NV的CEO Jesen Huang已经在DEMO医疗CT Real Time Ray Tracing 的3D成像了

    (如下右侧图像)

    在三角形体系的Ray Casting比较普遍,体数据上完成Monte Carlo Ray Tracing并且同时处理漫反射和镜面反射有

    一定的挑战,但目前已经越来越多,如下图(体渲染中光线追踪 并同时处理漫反射与镜面反射)

    虽然光线追踪已经越来越普及,但不同于可以使用商用渲染引擎,医疗中的渲染还是需要专门设计编写程序(私人订制),

    考虑医学图像本身的特点,所以还是有一定难度的。由于CT的数据场比超声数据场大不少,所以超声的实时光线追踪应该会比CT普及得更早

     

    电影《星际穿越》中的 卡冈图雅 黑洞渲染,为了符合物理规律(因为一般光线追踪假设光沿直线传播,但由于黑洞

    实际上会扭曲时空,光路也会扭曲),重新设计编写了新的光线追踪渲染,所以难度与成本陡然提升;

    PS:为了视觉效果,有些基础规则做了修改,仍不如1979年的模拟准确,人类目前最真实的基准还是EHT(事件视界望远镜)产生的图像;

    (左:星际穿越渲染的黑洞,中:1979年按天文学家给定的规则渲染的黑洞,右:2019年4月EHT发布的首张黑洞照片)

    对比之下,商用医疗3D的渲染进步的空间还很大。

     

    Others

    我们已经谈了很多图形学上技术,只是抛砖引玉,有很多没有展开: 如HDR, 光的衍射,运动拖影处理,折射(色散),菲尼尔,BDRF, Phase Function, Deferred Render(延迟渲染), 三角形体素化,体数据三角形化,物理引擎计算... ...等等。要接近真实,图形学依旧任重而道远。

     


    3. 图形学的未来发展

    最开始我们有提到,3D图形学的两个基本常态:

    1. 理论等待工程(软件&硬件)发展

    2. 效率是关键

    快,更快一直是不变的主题。

    硬件上

    硬件层面上无止境的提升不会停下,更重要的是架构级,底层级的变动,RT内核的加入是一个勇敢的尝试,市场会用脚投票告诉我们去往何方。但任何让硬件更快的努力,都是潜在的方向。

     

    软件上

    更快依然是主题,接管底层驱动级的控制是重大且艰难的一步,DXR对光线追踪的支持,DX12Vulkan代表的方向是重大的进步。但从上层算法到中层框架设计,再到底层驱动级控制 对图形学工程师提出了全栈能力的要求。

     

    工程师自己

    图形学的发展要靠 算法硬件软件的提升, 工程师能力的提升也很重要。有不少朋友总把GPU/GPGPU当万能解药,我做了对比实验,以CUDA的SDK自带的 DEMO中BOX Filter例子做比对基准,我自己写了个BOX Filter 的程序,同样的图像,运行在同样硬件上,同样滤波器尺寸,效率对比如下图(左:CUDA SDK自带的BOX Filter FPS 500+,右: 我自己在GL上的BOX Filter FPS 3500+)

    这个例子非常特殊,未必都能产生这么巨大的差距;

    我想表达的是,像我这样的业余3D爱好者都有可能做出这样的差别;这么多聪明的专业的3D工程师,如果深入专研,对效率上造成的改变将会是无法忽视的;提升工程师自身的能力,也是非常核心的因素;

     

    展开全文
  • 浅谈《原神》中的图形渲染技术

    千次阅读 多人点赞 2021-02-27 15:34:15
    从猜测的角度出发,谈谈《原神》中主要图形特效的渲染技术与优化方法。包括 LOD,PBR,环境光遮蔽,体积光,体积雾,视差,屏幕空间反射等常见的技术。

    前言

    在摸了一个寒假并且经历了【早上睡大觉,中午打原神,晚上英雄联盟,深夜看嘉然电棍炫狗大司马】的魔怔生活之后,终于决定来给自己的博客除下草,遂更新。

    玩了一个月的原神,我注意到了一些图形与渲染上的不错的细节,于是打算分享一蛤。本文将从 猜测 的角度出发,谈谈《原神》中主要图形特效的渲染技术与优化方法。

    本篇博客是杂谈类文章,仅代表个人猜想与看法,不保证正确,毕竟自己确实太菜,思路对不上米社的也大佬很正常 怎么我一开篇就搁这摆烂了

    不说批话了,开始!

    层次细节

    首先注意到《原神》是一个开放世界的游戏,这意味着场景非常大,那么绘制的三角形数目也非常多!如何解决巨量的 draw call 是一个首要的难题!

    场景非常大,这意味着一次性绘制所有物体变得不可能。别说绘制,就是把这些三维模型全部放进内存,显存中都很困难,毕竟游戏本体高达 30+ GB,而 NV 的老黄再怎么疯狂也不会造出一块 32 G 显存的显卡(谁知道呢,也许过两年就有了


    事实上,大多数的游戏都采样 LOD 技术来解决这个问题。LOD 技术全名为 Level Of Detail,即层次细节。LOD 的核心思想就是 “好钢用在刀刃上”,即 为近处的物体分配较高细节程度的模型,而远处的物体则分配较低细节程度的模型,以达到减少资源消耗的目的。事实上不止模型,模型对于的纹理等信息也会做相应的 LOD 处理。

    下图演示了不同细节程度的模型,较高细节程度的模型具有更好的品质,但是三角面片数目增加了,渲染的开销也增加了:

    在现实世界中也是如此。如下的照片中,远处的楼宇表面的瓷砖变得无法分辨,而近处的瓷砖则非常清晰:

    这告诉我们 无需为远处的楼宇绘制瓷砖,这也侧面证明了 LOD 技术能在不失真实感的情况下节省绘制的开销。


    来看《原神》中的 LOD 技术,在游戏中 LOD 分为三个层次,即远,中,近。三个层次的模型及其纹理具有显著的区别。注意拱门模型从远到近变化:

    可以看到随着距离的逼近,拱门的三角形面片数目逐渐增多,并且纹理逐渐清晰。

    除了模型的 LOD,纹理贴图也具有 LOD,通过访问低分辨率的纹理以降低开销,下面是游戏中纹理的 LOD 效果,注意从远到近地上的白色纹理逐渐清晰:


    如果你的眼睛足够锐利,可以察觉到 2 条纹理等级分割线。在不同距离切换使用不同分辨率的纹理。虽然 gif 被压缩了并不明显

    纹理的 LOD 技术可以由显卡驱动负责,根据指定的 LOD 等级,以 2 的次方的大小来生成逐步缩小的纹理,这也是为何远处的物体纹理都非常 “马赛克” 的原因:

    一张正方形砖墙生成的 LOD 纹理大概如下,纹理查询算法会按照我们的要求,去选取一张最合适的分辨率:

    此外,在多光源光照的处理上,也使用了 LOD 技术。因为光照计算非常宝贵,没有必要为远处的非常小的场景计算宝贵的光照。此外,图形程序员还为 LOD 光源在最大距离处添加了一个线性的淡入淡出的效果,防止画面突然闪烁。注意远处的灯逐渐亮起:


    层次细节技术能够给予场景更大的体量,同时保持低消耗。于是美工需要准备好几套不同层次细节程度的模型,在绘制之前,我们根据摄像机到模型的距离,来判断应该选取何种程度的模型进行绘制即可。

    PBR渲染方程

    PBR 又名 physically based render,即基于物理的渲染。是迪士尼提出的一种能够在实时渲染上面逼近真实图像的渲染模型。PBR 不仅能够以较小的代价获取很高质量的材质渲染感,而且一定程度上规范了模型素材的材质格式。下图是典型的 PBR 渲染效果图:

    注:
    图片引自博客 《PBR 渲染之你上你也行!》
    好吧这只是个人翻译,原文叫:physically based rendering and you can too

    在现代计算机游戏上,PBR 已经成为了一种标配的渲染方式,或者说一种 “流程”,在原神中也不例外的使用了 PBR 作为渲染,并且拥有一套自己的风格:

    PBR 包括一套非常复杂的公式和其背后的物理原理,比如漫反射,镜面反射,菲涅尔效应等。下面细说。


    在传统的 phong 光照模型中,简单通过光源和法向量的夹角,来获取一个点的颜色。对于所有的物体都有同样的公式,这意味着无法区别不同的材质。事实上传统的 phong 光照模型渲染出来的东西像塑料一样:

    而 PBR 渲染则通过指定一系列的参数,来从物理上逼近不同的材质,从金属到木头,都可以通过美术设计者指定的参数与纹理进行规格化的渲染。PBR 的规范化流程表明,在美工制作完成 PBR 的素材之后,在游戏中也会有相同视觉效果。下图展示了 PBR 强大的模拟能力:

    注:
    图片引自 迪士尼的一篇 talk,是讲 BRDF 的,十分深奥
    这种级别的 talk 不是我这纯种啥卵能够玩明白的,于是只偷了张图过来凑合一下。。。

    来看一组《原神》中的截图:通过 PBR 渲染方程,可以模拟不同的材质表面。从左到右从上到下分别是石头,砖块,木头,瓦片,漆木,大理石。这足以秀一下 PBR 的肌肉:

    在 PBR 中,通过一些规范化的纹理贴图,来描述不同的材质的参数,进而根据 PBR 的公式得出不同的结果,这些贴图包括:

    • 法向贴图
    • 金属度贴图
    • 反照率贴图
    • 粗糙度贴图
    • 环境立方体贴图
    • 环境光遮蔽贴图
    • 其他…

    这些贴图提供的信息用以辅助 PBR 公式并且得出正确的结果。PBR 的难点就在于公式非常繁杂,下面给出 PBR 的基本公式:

    L = ∫ ( k d C o π + k s D   G   F 4 ( N ⋅ ω 0 ) ( N ⋅ ω i ) ) ( N ⋅ ω i )   C l   d ω i L=\int \left( k_d \frac{C_o}{\pi}+ k_s \frac{D \ G \ F}{4(N \cdot \omega_0)(N \cdot \omega_i)} \right) (N \cdot \omega_i) \ C_l \ d\omega_i L=(kdπCo+ks4(Nω0)(Nωi)D G F)(Nωi) Cl dωi

    和大多数渲染方程类似,PBR 默认使用路径追踪式的定义,即 ω 0 \omega_0 ω0 为入射光线(射入人眼), ω i \omega_i ωi 为出射光线(射向光源),或者说来自光源的光线的反方向:

    此外, N N N 是法向量, k d k_d kd k s k_s ks 分别表示了漫反射和镜面反射的占比系数, C o C_o Co 是材质贴图原始颜色, C l C_l Cl 则是灯光颜色。再来看剩下的 DFG 三兄弟:

    其中 D D D 表示微平面分布函数,也就是镜面反射的波峰函数。在 phong 光照模型中,通常用 ( cos ⁡ θ ) α (\cos \theta) ^ \alpha (cosθ)α 来近似,而 PBR 使用多种复杂的近似函数比如 GGX 等,这里不细说了。

    F F F 表示菲涅尔效应,通常使用 Schlick Fresnel 来近似,就是那个著名的 ( 1 − cos ⁡ θ ) 5 (1-\cos\theta)^5 (1cosθ)5

    再来看 G G G,表示几何遮蔽。唔… 说实话我没搞懂这一项到底是离线烘培的模型环境光遮蔽,还是高光的次级波瓣近似,先挖个坑(逃

    注意到下图中,大理石材质的反光效果就是基于 PBR 技术渲染的。通过一定的反射系数,可以反射来自光源的高光:

    除了来自光源的高光,PBR 还允许镜面反射的光线源来自周围的环境立方图。比如下图的地面反射就采样于环境立方图。没有芭芭拉的倒影表明我们并未开启 SSR,这是单纯靠渲染方程的反射:

    静态的环境立方体贴图在游戏开发的时候就离线渲染好了,我们计算相机到像素的光线的 反射光线 的方向,然后再根据这个方向,去环境立方图里面采样:

    此外,如果你足够细心,就可以在游戏中发现这样子的立方体贴图分界线。开发者为了适应不同的环境,根据当前像素的不同位置,选取不同的立方图进行采样。好吧,其实分界挺明显的,晃动镜头就可以看出区别:

    此外,留意地面上的因为瓷砖不平整产生的扭曲,这要归功于我们的法线贴图。

    IBL环境光照

    除了反射贴图,对于环境光(Ambient)也有对应的贴图。在普通的 phong 光照模型中,ambient 项是一个常数。而 PBR 允许我们利用一张环境立方图来描述场景的环境光,这项技术也叫做 IBL,Image Based Lighting,即基于图像的光照。

    通常在离线的状态下预先烘培一张环境光贴图即可,并且环境光贴图通常是由镜面反射的立方图贴图通过模糊而得到的,比如:

    注:
    图片引自:Using Image Based Lighting (IBL)
    塞拉斯的大招转的太快辣

    和镜面反射的环境立方体贴图类似,只是我们把采样作为 Ambient 项进行计算。下图是一个典型的 IBL 的效果。在没有光源的情况下,左边的地面呈现红色,而右边的地面呈现原本的颜色:

    再补一张图,可以清晰的看出来 IBL 的效果还是非常真实的,并且具有很高的正确性。左侧的阁楼灯火通明,所以提供的环境光应当偏红,而右侧的楼梯面朝大海,环境光偏蓝,如图:

    米哈游在 2020 的 Unity 大会上的 talk 也提到了 Ambient 探针,球体的演示能够更加生动:

    注:
    原文地址:https://www.bilibili.com/read/cv8444599/

    此外,该 talk 还提到了在室内外使用不同的环境光立方图贴图,并且需要美工人为地给模型的顶点标记上室内室外,同时在室内室外切换的时候做一个线性插值。

    集群延迟光照

    在游戏中拥有众多的光源,而多光源的渲染一直是拖慢实时渲染的主要因素。如图,游戏场景中拥有数十个光源:

    正常的思路是遍历所有的光源并且计算光照,这意味着场景的光源增多一倍,渲染的代价也要翻倍。这是几乎不能接受的!

    事实上,在 Unity 2020 的 talk 中,开发者也谈到了《原神》采用的是 Clustered deferred lighting 的策略去处理大量的灯光。

    Clustered deferred lighting 即 集群延迟着色,是 “集群” 与 “延迟着色” 两种思路的结合。抛开集群不谈,我们先来看看 “延迟渲染” 这一伟大的思想:


    在前向渲染(也就是比较远古的时候)大家都直接 draw call,然后运行片段着色器计算光照。这样做的效率非常低下,我们来算一笔账:

    假设有 n n n 盏灯, 100 , 000 100,000 100,000 个三角形,平均每个三角形能够产生 300 300 300 个像素,那么最终需要运行

    t 1 = n ∗ 100000 ∗ 300 = 30 , 000 , 000 t_1 = n * 100000 * 300 = 30,000,000 t1=n100000300=30,000,000

    次片段着色器,这意味着我们执行了 t 1 t_1 t1 次光照算法。这显然是没有必要的,因为片元着色器运行在深度测试之前,这意味着我们 对被遮挡的像素也计算了光照 ,而这些计算显然是没有必要的!


    于是提出了延迟渲染的概念,延迟渲染的核心思想就是在深度测试之后再计算光照,这样只对我们看得见的物体计算光照,确保好钢用在刀刃上。

    回想光照的计算需要那些信息:片元法线,片元位置,片元材质,光源位置… 延迟渲染预先将这些信息存储在一些缓冲中,这些缓冲叫做 g-buffer。

    下图是 CryEngine 在 2013 年的《孤岛危机3》(又名显卡危机3)中首次使用的延迟渲染 g-buffer,正是这些信息支持了光照的计算:

    注:
    这里没有世界坐标纹理,因为世界坐标可以通过其他途径获得:
    这里世界坐标可以通过 ndc 坐标 + 投影矩阵的逆矩阵解算出来
    而 ndc 坐标可以通过深度图(Depth,z axis)和像素坐标(x y axis)进行重建
    相信大家都懂,我就不细🔒了(逃

    在真正计算光照的时候,我们从 g-buffer 中取出信息,并且实际地执行光照计算。这里贴一张我以前的博客的图(忽略那个 shadowmap 吧 Orz):


    屏幕有多少像素,后处理阶段的片段着色器就跑多少次。那么计算光照的复杂度就只和 屏幕分辨率 ,光源数目有关,我们只需计算:

    t 2 = n ∗ 1920 ∗ 1080 = 2 , 073 , 600 t_2=n*1920*1080=2,073,600 t2=n19201080=2,073,600

    这么多次光照即可。因为深度测试帮我们剔除了很多看不见的像素,所以绘制的开销得以降低。

    事实表明延迟渲染是非常棒的优化策略,可以降低一个数量级的开销。如图展示了拥有 1800 个光源的渲染场景,而这在前向渲染下几乎是不可能的:

    在了解了延迟渲染之后,再来谈谈 “集群” 的思路。emmm 如果了的并不是很解,可以康康我之前的博客:

    OpenGL学习(十一):延迟渲染管线

    或者是参考 Learn OpenGL 的相关章节 以获取更加权威的资讯


    使用延迟着色法渲染光源仍然有可以优化的空间,因为 每个像素仅受部分灯光的影响,无需对所有的灯光都计算光照。

    首先从直觉上来讲,灯光只会影响一定范围内的像素。对于 距离过远 的像素则不受灯光的影响,这样更加符合常理,此外,在背面 被遮挡 的像素也不需要计算光照:

    因为过远或者背光的像素不需要计算光照,于是每个像素都拥有一个独属于他的灯光集合。下图中,区域 1 受两盏灯的影响,而区域 2 只受一盏灯,他们有不同的灯光集合:

    对于一个拥有 100 个光源的大场景,假设一个点平均受 10 个光源的影响,那么比起遍历所有的光源,仅遍历影响该点的光源,减少了 90 次的计算!

    还有一个小问题:计算有效灯光集合的复杂度。如果对每一个像素,都遍历所有灯光并且筛选出有效的灯光,这和我们暴力计算没有复杂度区别,坏了。

    事实上 互相邻近像素都受同一组灯光的影响,于是引入集群的思想。集群灯光的处理分为三个主要步骤:

    1. 先根据场景信息(比如位置,法线)将场景分为不同的 集群
    2. 然后对每个集群,计算影响该 集群 的灯光
    3. 最后计算光照时,先找到 像素 所在的 集群 ,然后遍历影响该集群的所有灯,同时计算光照

    如图展示了不同集群寻找灯光的大概过程。首先找到该像素所在的集群,然后根据集群,索引影响该像素的灯光:

    一种经典的划分集群的方式是根据空间位置进行划分。将相机的视锥体分为若干个子区域。可以按照 xy 方向先划分出 tile,再在深度方向上继续细分:

    当然也有其他划分集群的算法,比如加入法线,深度信息等等,这里就不详细讨论了。但是思路大体是这样子。对于无效光源越频繁出现的场景,集群的思路能够让渲染的效率成倍提升!

    实时阴影

    聊完光照,再来看看计算机游戏中必不可少的特效之一:实时阴影。游戏中的实时阴影分为很多个部分:

    • 太阳阴影(正交投影的 shadow mapping)
    • 光源阴影
    • 室内点光源(点光源的 omnidirectional shadow mapping)
    • 云阴影

    经典算法 shadow maaping 通过从光源方向渲染一张深度纹理,以获取离光源最近的物体的距离 closestDepth。然后再判断目标片元到光源的距离 currentDepth 是否大于最近物体,如果是,那么目标片元处于阴影中,图解如下:

    我之前的博客写过一次:OpenGL学习(九)阴影映射,这里直接偷了

    因为 shadow mapping 的原理比较简单,同时开销较小,所以一般的游戏都采用这种方法绘制实时阴影,《原神》也不例外。


    首先来看直接阴影。直接阴影是最常见的阴影,由太阳发出的平行光投射而成:

    平行光的 shadow mapping 代码并不难写,但是要在一个宏大的场景下使用 shadow mapping,就需要渲染一张分辨率非常高的阴影贴图,否则渲染出来的阴影就会有很多锯齿,并且精度非常低:

    这里偷了 Learn OpenGL 的图,我太懒了。。。

    而《原神》的开放世界需要有很远的能见度,即使在最低的阴影质量下,在超远视距的情况下也可以渲染出阴影,并且优化还不错,如下图,这是一个非常夸张的距离:

    而米忽悠也在上文提到的那个 Unity 2020 的 talk 中表明了优化方法。米忽悠使用 Cascaded shadow map,也就是级联阴影映射技术来对阴影进行优化。级联阴影映射和 LOD 技术异曲同工,即 近处的景物使用高分辨率的阴影贴图,远处则使用低分辨率 。将透视投影的视锥体分为几个片段,然后用不同分辨率来渲染阴影贴图:

    注:
    上图不完全正确
    因为不同距离的阴影贴图能看到的景物不同,而不是像上图的右侧一样渲染出不同分辨率的相同物体

    而在米哈游的那个 talk 中提到,相比于传统的 4 级划分,《原神》的阴影渲染采用了非常变态的 8 级阴影贴图的划分,以保证远景和近景具有足够的品质。

    此外,采用延迟更新的 “shadow cache” 策略,前 4 级 cache 每一帧保证更新一次,而后 4 级 cache 则轮流更新(因为是远景区别不大),这样每一帧只需要更新 5 张贴图。


    再来看软阴影。因为阴影贴图会产生锯齿,而且现实中的阴影一般不会非常棱角分明。相反,现实中的阴影会随着和投影物体的距离的增大,而逐渐模糊,如图是照片中的两个小片段:

    而在游戏中使用了随机分布的点,对阴影贴图进行了多次采样,从而判断一个点在阴影中的程度,以达到模糊的效果,而非传统的高斯模糊。因为前者具有更好的品质。

    talk 中提到使用的是泊松分布,并且进行了 11 次采样。此外,通过对随机序列进行旋转,进一步提升软阴影的品质,同时避免重复的图样(pattern)出现。

    而米社有说使用了基于距离的软阴影,emmm 在实际游戏中我貌似没有明显地察觉到。下图理论上应该是腿部的阴影较为尖锐,而头部的阴影较为模糊才对,而我并没有看出来:

    好吧。。。可能这个特效是 ps 版的特供?毕竟抛开软阴影这一套重量级的流程,再执行一次模糊处理确实有点捉襟见肘。

    正是因为这一套组合拳开销太大,无需对每一个像素都做,我们 只需要对阴影边缘的像素做一次软阴影 即可。于是米忽悠搞了张 mask 的图以标记阴影的属性,是阴影,半影,还是不在阴影中。红色的区域表明是阴影的边缘,我们应该计算软阴影:

    通过对原始阴影贴图的 “田” 字型的 4x4=16 个像素进行采样来判断当前点的阴影程度,然后输出到 mask 贴图中。因此这个 mask 的分辨率是原图的 1/4,此外,16 个像素的开销还是大,于是只在 16 里面取部分像素的结果输出到 mask 贴图,虽然不正确,但是经过模糊处理,仍然能够得到不错的结果。

    具体怎么取?米忽悠没说,我也不知道,那你去找物管啊


    再来看光源阴影。在游戏中的一些光源也拥有实时阴影,和平行光最大的区别就是阴影会随着人物的移动而发生形变。因为来自太阳的平行光,在程序上会人为 地将太阳光源和摄像机绑定着一起移动,而场景的局部光源则不会:


    这种光源的实时阴影在场景中大量存在,不得不考虑性能问题。在实际渲染中是通过两种方式获得阴影贴图:

    • 对于静态的物体,离线烘培一张阴影贴图
    • 对于动态的物体(比如玩家)则实时从光源方向渲染阴影贴图

    这么做的好处就是减少了不必要的 draw call,因为绘制阴影贴图也需要调用 draw call 的。

    下面的图揭示了有趣的现象:楼梯和栏杆属于静态物体,使用预先绘制的阴影贴图。而玩家人物则属于动态物体,拥有实时阴影贴图。两位路人则没这好待遇,于是没有影子:

    此外,对于太阳光造成的阴影,可以和人造光源的阴影同时存在。如下图:

    关于动态阴影,原理也不是很复杂。根据片元的位置,选择能够影响它的光源,然后循环计算 shadow mapping 即可。值得注意的是,这一步可以使用上文提到的 集群光照计算的策略

    从截图可以看到,随着距离的靠近,光照和阴影被计算,并且是 同时 出现的。这说明光照和实时阴影可能在同一个 pass 中被计算:

    以上的两种阴影都是平行光的阴影,再来看另一种 “点光源” 的实时阴影


    平行光阴影的特点是一旦物体在光源背后,就无法产生投影。而点光源阴影则没有这种限制,在光源的任意方向上都能够产生投影:

    在游戏中的室内场景就能见到这种投影方式。可以看到在光源的任意方向,都可以产生投影,即使投影处的高度已经超过灯:

    事实上通过 omnidirectional shadow mapping 技术就可以实现。听起来很 gds,其实很简单,就是在点光源的 上下左右前后 6 个方向上面各做一次 shadow mapping ,然后得到 6 张阴影贴图,在计算的时候根据像素位置,去对应的阴影贴图中取数据即可。


    最后是云阴影,实际上游戏中并没有实时的云阴影,那些阴影都是利用像素的世界坐标的 xz 轴,从一张 2D 的噪声图中采样然后直接贴上去的:

    在有云阴影的位置,天空上的云并不与之对应。事实上游戏中很少有玩家能够接触到的体积云,除了巨神峰和某个秘境之外

    环境光遮蔽

    环境光遮蔽(Ambient Occlusion)用以补充光照不足且褶皱较多的场景的细节度。在开始介绍《原神》中的 AO 技术之前,先来看看现实中的 AO 效果。

    环境光遮蔽就是环境光造成的阴影。在两个物体相邻但是不贴在一起的时候,一个物体往往会挡住射向另一个物体的环境光,并且 投射出微弱的阴影

    注意下图:牙刷,沐浴露,书架分别在后面的 墙上 投射出遮蔽的阴影,并且阴影的强度随着他们距离墙的距离的减少而增加:

    为了拍摄这幅图片我的牙刷刷墙了 3 次


    环境光遮蔽能够显著地提升场景的表现能力,尤其是在弱光照的情况下,因为环境光遮蔽模拟了物体之间的层次情况。下面来对比一下有无环境光遮蔽的场景:

    可以明显的看到,在没有太阳直射的时候,环境光遮蔽帮我们体现了场景的层次。如果单看左边,我们还以为城墙到底是一张贴图,而右边的带有环境光遮蔽的场景告诉我们,中间的城墙是凹下去的。

    因为没有太阳直射,那么渲染方程中的 Ambient 项几乎是一个常数(尽管有 IBL 来帮忙但是还是不明显)于是所有物体都体现出同样的亮度,而引入环境光遮蔽之后,物体的颜色和位置有了关联,场景的保真度也就提升了。


    再来看游戏中的环境光遮蔽。游戏中的 AO 分为 3 种不同的实现:

    1. HBAO,经典通用算法
    2. 体素 AO,用于静态物体
    3. 胶囊 AO,用于动态物体,比如玩家

    其中各种方法取长补短,共同组成了最终场景的 AO 效果。我们从最基础的 AO 开始说起。在这之前记住:几乎任何 AO 的核心都是判断一个像素 受到遮挡的程度

    在 2007 年的孤岛危机 1 中首次提出 SSAO 的概念。SSAO 又名屏幕空间环境光屏蔽(Screen Space Ambient Occlusion),通过屏幕空间的深度信息来判断遮挡程度。在 SSAO 中怎么判断呢?其实就是在点的周围采样一圈:

    通过深度图(比对采样深度和测试深度)来判断采样的位置是否遮挡目标像素,这和 ray marching 算法的求交类似。如果采样总是被遮挡(对应上图红色箭头)那么反应了该点的遮蔽程度较高。

    再来看 HBAO,HBAO 全名 Horizon Based Ambient Occlusion,不同于 SSAO 的一个方向一次采样,HBAO 使用 ray marching 策略进行一个方向多次采样,并且通过深度图得到一个 “高度场” 再根据高度场的信息得到视野角(horizon angle)通过视野角来描述该点被遮挡的程度:

    此外还有一些 trick,比如随机旋转方向,模糊,时间滤波(类似 TAA)等,这里游戏中应该是实现了随机+模糊,算是一套常规的实现,对于任意大小的场景都能有较好的效果,注意墙上书本的投影:

    因为是屏幕空间的算法,不在屏幕空间内的物体就无法产生遮挡,此外对于采样的距离我们也不好把握。距离大了,容易造成误判,距离小了又不能体现远端物体的遮挡,于是引入另一种方法:volume AO


    volume AO 利用预先烘培的三维信息来计算遮挡。相比于上文提到的实时 AO,volume AO 适用于静态物体。在离线环境下记录物体的遮挡信息(最简单的比如存放 01 以表示该位置有无物体)并且存放在 volume texture(一种存储 3D 信息的纹理)中。在绘制 AO 的时候通过对 3D 纹理的查询可以获取屏幕空间之外的信息。

    volume AO 是对基础 AO 的一种补充。比如下图中,volume AO 就可以绘制一些常规算法难以绘制的 ”死角“ 。遮挡信息也很灵活,既可以是预先绘制好的 AO map,也可以单纯存储物体的 type 或者 id …

    唔。。。在米忽悠自己的 Unity 2020 talk 中提到了 volume AO 的效果:

    但是实际游戏中,我把特效拉满也无法复现这个效果,可能是 ps 独占?或者我的 A 卡不支持?如图:

    我倒是在教堂里面发现了奇怪的疑似体积 AO 的东西。注意下图中凳子下方的很淡的阴影,即使特效开极低也存在:

    好吧不管力。。。快进到下一个

    遮挡信息预先存储,volume AO 对于动态物体(比如玩家)就无能为力了,于是还有一种专门为了绘制动态人物的方法。


    利用 capsule AO 来为动态的人物绘制环境光遮蔽。capsule AO 人如其名,用类似 “胶囊” 的包围盒包住人物的四肢:

    在计算 AO 的时候遍历这些胶囊,判断是否对当前像素造成遮挡即可。事实上人物向墙面的投影就是用这种方式计算的:

    注意 椅子并没有产生环境光遮蔽 ,而人物模型却产生了。这是因为常规的 AO 算法都有一定的角度的限制,在比较极端的角度无法有效的工作。这也侧面说明了《原神》中的 AO 是多种技术的混合。

    体积特效

    体积特效分为体积光和体积雾,两者都是使用 ray marching 算法实现的。关于 ray march 可以看看我之前的博客:体积云渲染实战

    这里简单提一下,就是发射光线,记录信息,没了!下面是体积云的 ray march 示意图(是的,我懒得重新画了)而 “相交” 判断的不同,能够造成不同效果的绘制。


    比如体积云是根据 3D 的密度函数来判断采样是否在云层中。体积光是通过将坐标转换到光源视角,同时做一次深度的判断来检验采样点是否暴露在光源之下(有点像 shadow map)


    先来看体积光。体积光分为两种绘制方式,分别是贴图和 ray march。前者单纯是一张静态的贴图,而后者可以根据光被遮挡的情况正确的呈现,因为后者严格按照视觉规律进行模拟计算:

    再来看一张有意思的图:因为 ray march 的步长不够,走到一半循环就结束了,于是在距离山体较近的地方,体积光缺了一截:

    步长限制了渲染范围,这也是 ray march 的通病了,有很多 trick 可以改进,这里就不展开细说了。


    再把目光放到体积雾上边。体积雾的效果乍一看好像和基于距离的线性(或者指数)雾没啥区别:

    但事实上线性雾的颜色仅来源于两个信息:距离,视线方向。虽然我们可以通过视线方向和太阳位置的偏差来绘制夕阳下的雾,并且大多数情况下都是好用的。图为 关闭 体积雾时的效果:

    但是人类的贪欲永远没有极限。如果想为每一盏灯也绘制照亮雾的效果,比如下图的照片是有一次深夜坐地铁的时候拍的,高楼上的工地亮着的大灯能够照亮旁边的雾:

    猜猜这是科苑站的那个出口?
    A. B, B. D, C. A D. C

    那么传统的线性雾就没办法做到。因为灯光是从相机到目标片元路途上的信息,只有通过 ray march 老老实实地一步一步去记录,才能正确地绘制。

    如果 ray march 的过程中遇到的位置属于光源范围,那么就积累亮度,这就是基本的思路。下图是《原神》中关闭了 bloom 的情况下,开启体积雾而产生的效果:

    可以看到光源很好的点亮了雾。而光源的信息和前文的 volume AO 一样,存储于 3D 的体素纹理中。我估计美工在设置的时候,光源的体积应该略大于实际模型,这样才能造成 “扩散” 的感觉。

    还有很重要的一点:如何优化性能?采样次数是最主要的指标。减少采样次数,图像会变得非常 “破碎” 且 “层次分明”,使用随机步长以减少图像的 分层感。而随机的步长则会带来噪声,如图:

    使用时间滤波的思路处理噪声,比如 TAA 抗锯齿就是这么弄的,然后可以得到能够接受的结果:

    注:
    上图引自游戏《INSIDE》在 GDC 上的 talk 的 ppt
    原视频可以看油管:传送门,14 分 40 秒左右
    因为《原神》肯定不会把没 de noise 的 debug 版放出来给玩家,于是只能偷别的游戏的图了。。。
    他两游戏的体积特效的优化方式都是类似的,随机步长+TAA

    屏幕空间反射

    PBR 中虽然有反射方程,但是图像来源却是预先绘制的立方体贴图,或者说 reflection probe(反射探针)那么反射的位置当且仅当 渲染相机和绘制立方体贴图时的预处理相机位于相同位置 时,才能得到正确的反射。

    否则无法做到完全正确的镜面的反射。比如下图反射的物体和实际的物体对不上,注意下图中的三根柱子的位置和反射的位置其实是错位的:

    此外,不在环境立方图里面的物体也不会被反射,比如玩家,或者是路人 NPC,如图:

    于是便需要屏幕空间反射来补全缺失的 营养 这一块。可以看到屏幕空间反射的效果十分正确:

    屏幕空间反射又名 SSR,能够从物理上模拟光的步进,并且通过和类似 ray march 的方式,一步一步步进,最终找到镜面反射的像素的来源:


    注:
    此图来自于我之前的博客:从零开始编写minecraft光影包(9)高级水面绘制
    没错,又偷了!我摆烂了

    而屏幕空间反射的缺点就是只能反射屏幕空间的东西,换句话说,你看得到的东西才会被反射,如图,视线范围内的柱子才拥有反射:

    此外,《原神》中的屏幕空间反射也遵循菲涅尔定律。菲涅尔定律告诉我们:平视镜面的时候反射光居多,而俯视镜面的时候反射光偏少:

    在游戏中的反射也存在相同的近似,注意一排灯光的亮度,随着视角角度的减小而衰减:

    此外,在反射的边缘,SSR 会和 PBR 的反射做一个插值以求尽量平滑过渡。好吧,也不平滑。。。

    视差

    视差贴图通过高度纹理,描述物体表面的高度,并且能够模拟具有巨量微结构的物体。要知道这在传统绘制中需要倍增十几倍的 mesh 才能做到。一张典型的视差贴图效果如下:

    上图仅使用了一个四边形,就模拟出数十个四边形才能实现的凹凸效果。这是一种视觉上的欺骗。

    视差贴图通过摄像机的角度,和平面的高度纹理,计算出一个 偏移的纹理坐标 ,以欺骗我们的眼睛。以二维为例。假设视线射向平面,那么对于 A 点,应该去 A 点的纹理处采样:

    而高度图告诉我们,平面上 A 点的高度是 h,那么视线实际射到的是 B 点,于是我们要采样 B 点对应的纹理值,这样你的眼睛会认为你看到了 B 点:

    通过射向 A 点的射线,和 A 点的高度,计算出纹理坐标的偏移量,就是上图中 A 到 B 实际需要偏移的纹理坐标。然后利用偏移的纹理坐标实际采样纹理,即可模拟凹凸表面。下面是《原神》中的视差效果:

    注:
    有多种方法可以计算视差的纹理偏移量,可以参考:Learn OpenGL

    植物渲染

    唔。。。植物的渲染一直是比较蛋疼的,要想在性能和美观上取得平衡非常不易。下面是《原神》中大量植物的场景:

    要想模拟枝繁叶茂,就需要很多的 mesh,比如下图是一个非常逼真的松树,包含了 55336 个三角形,非常恐怖:

    而实时游戏,光这一棵树都承受不起了,别说一群了!

    事实上现代游戏中,植物总是作为透明物体被渲染。通常使用一个或者多个三角面片就可以表示,然后贴个带 alpha 通道的透明贴图,在 alpha 通道显示透明度为 1 的地方都没有颜色,于是可以直接看到后面的场景,就好像真的有这么多叶子一样:

    事实上从极端的侧面角度看过去,任然能够看到植物渲染的时候,原本的三角面片的结构就会暴露无遗:

    此外,对于远端的树木或者植被,因为 LOD 需要,干脆直接不渲染 3D 的模型了,改用一个四方形 + 贴图的形式。如图:

    关于植物渲染,除了节省开销以外,如何更加真实的模拟自然植物的物理现象也很重要。还有一个小细节:当玩家走过草的时候,草会被压弯:

    这个特效也不难实现,在顶点着色器中,将草的顶部顶点,根据玩家和草顶点的位置向量,做一个偏移即可:

    注:这里是错切变化
    因为没有装 ps 所以没法绘制正确的错切图,意思到了就行(摆烂x3

    至于顶点着色器怎么判断是草的顶部顶点?估计是美工刷了个顶点属性上去,然后顶点着色器特判一下即可。或者通过当前顶点和地形的高度差来判断,方法有很多。。。

    反向动力学骨骼

    你可能注意到一个细节:当人物站在高度不一致的平面上时,左右脚会自动调整 y 的位置,并且带动大腿小腿同时调整:

    仅调整脚部的位置不难,难点是如何通过脚部 y 的变化,来调整其父骨骼,爷骨骼的变化。这就是反向动力学骨骼。下图为 mikumikudance 里面的反向动力学骨骼的效果:


    可以看到在仅调整脚部 y 坐标的情况下,整条腿都发生了变化。只有两条骨骼的情况下很容易调整,通过简单的余弦定理即可,因为骨骼的长度总是固定不变的,通过三角形的三个边长,确定对应的角度,不是什么困难的事情:

    当然,任何一个游戏的模型都不可能这么简单,除了 y 轴,还有 xz 轴的骨骼,他们拥有更加复杂的变化,并且有时候会出现非常冗长的 IK 链,这就需要一些算法去通过子骨骼的变化来解算父骨骼的变化。

    不仅脚部拥有这个特性,人物的手部也有。在爬山爬墙的时候,玩家的手总是能够 “自适应” 凹凸不平的表面,这也是反向动力学骨骼解算的结果:

    当然,这些算法并不是任何时候都能起作用,比如,额:


    至此,本文的最后一个讨论正式结束。但是现代计算机游戏的种种技术远不是一篇文章能够简单谈完的,这是无数的厂商,程序员,软硬件工程师,科学家日夜奋斗的结晶。

    希望大家能够通过这篇文章,对现代计算机图形技术有一个管中窥豹的认识,能够大概的知晓屏幕上面的芭芭拉是通过一系列精妙的算法得到的,而不是魔理沙的月球魔法。(这句我在我之前的博客也用过,经典偷过来

    后记

    唔。。。现在是 3 月 12 日的凌晨了,事实上我在 2 月下旬就起草了文章,结果中间一直摸,直到今天这个大坑今天算是填完了?

    时间飞逝,而我的魔怔程度却丝毫不减。今年年初立了个 flag 我的 光线追踪的那篇博客 会是今年最长,看来这一下子就回收了。。。

    其实文章的完成并没有想象中的顺利。第一次写这种杂谈类型的文章,从一开始的不知如何下手,到磕磕绊绊地码公式,查资料,看 talk,包括但不限于顶着极低的帧率,顶着 100% 的 CPU 和 GPU 在敲 markdown,还要提防好机油们来我世界偷菜… 好在这些我都扛过来了

    令我意外的是,拥有国内顶级技术力的《原神》开发组竟然没有使用一些比较新的技术,比如光追。不过鉴于技术总监的原话:“时间紧,只能选择成熟稳定的技术,没有时间试错!”,并且《原神》需要跨平台,优化与稳定才是大头,所以也算是意料之外情理之中

    话说回来,在完成这篇文章之后,我也算是对实下游戏图形渲染方向有了大概的了解,俗话说罗马不是一天建成的,但至少在这个潮湿的 3 月我迈出了小小的一步。

    从上高中起我就想当图程,当时是玩 mc 光影入的坑,特别膜 SE,也就是 SEUS 光影作者。和大多数同学不同,我写的第一个程序不是 hello world,而是 color.g *= 2;,并且在 mc 里面将一切都变得 “绿色” 起来。

    尽管一路上见证了互联网的兴起与内卷,人工智能的猛烈,并且身边的人都和我江:图程毕业即失业。在这之前我也非常迷茫,自己是否选择了计算机中的 “生化环材” ?带着疑问,我开始登山,并且敲下本篇文章的第一个字符。

    说巧不巧,在敲上面那句话的时候,刚好响起了我最喜欢的一首车万同人曲《Can’t look away》

    V 姐带着法国 + 日本口音的英语响起:“追逐梦想是非常短暂的,过不了多久我便无法控制,我已经做出了改变,现在我无法离开”

    在这里插入图片描述

    再回头看看,我想,我有了自己的答案。

    十年前 vulkan 横空出世之时大喊我是你爹,众人高呼 OpenGL 死刑立即执行。在蹉跎之间,与 vulkan 和 d3d 两座大山夹击之下,GL 不仅没寄,而且 +1s,此外 ue 依然火热并且最近要出 ⑤,cocos2D 活跃在小游戏,而 unity 有式微之趋,要知道当年 u3d 可是仌,而 coco 半截身子已经埋在土里了… 所以未来是啥样子捏?狗都不知道!

    emm 写完后记百感交集却又哽咽,在这里在立个 flag 吧,无论在那个 branch 上,我都希望以后的我对今天的我说:“这把不选卢仙,啥b!”

    展开全文
  • 次世代角色渲染技术概述

    千次阅读 2019-09-28 14:59:09
    在上篇给读者介绍了关于卡通渲染的一些技术点,本篇再介绍一下关于次世代角色渲染技术,市面上占主流的游戏还是大型的次世代渲染,Unity自身提供了Standard和Standard(Specular),但是对于游戏的品质来说还远远不够...

    在上篇给读者介绍了关于卡通渲染的一些技术点,本篇再介绍一下关于次世代角色渲染技术,市面上占主流的游戏还是大型的次世代渲染,Unity自身提供了Standard和Standard(Specular),但是对于游戏的品质来说还远远不够,而且相对来说比较耗,这就需要我们自己去提升,其实新版的Unity给我们提供了Shader Graph作为Shader工具来说还是可以使用的,它相比Shader Forge好很多的。次世代渲染也可以成为PBR渲染,我们将它拆分开,涉及到的渲染技术如下所示:
    在这里插入图片描述
    以上就是我们实现次世代渲染使用的技术点,在这里就不介绍算法方程了,想具体了解的读者可以自行查阅,其实已经有人帮助我们实现了,在这里我们自己首先要知道如何使用它们?先给读者看一下实现的效果图:
    在这里插入图片描述
    该模型实现了次世代渲染效果,高光,法线,反射,遮挡等等都实现了,其实我们只用了三张贴图,如下所示:
    在这里插入图片描述
    为什么三张贴图就可以实现次世代效果?这里使用了图片的合并,第一张贴图和第二张贴图一目了然,重点看第三章贴图,在这里我们使用了多张贴图的合并,我们知道贴图的颜色是由RGBA组成的,那么我们合并的贴图也是通过RGBA表示的,我们的R表示的是Metallic,G表示的是Smoothness,B表示的是Glow,A表示的是Occlusion。这样我们也达到了优化的目的,看一下在Shader Graph中的效果图:
    在这里插入图片描述
    合并图片的目的是为了减少系统的吞吐量,再就是也是优化角色渲染,我们把第三张贴图给读者分解,如下所示:
    在这里插入图片描述
    贴图处理的核心代码如下所示:

    			SurfaceOutputStandard s6 = (SurfaceOutputStandard ) 0;
    			float2 uv_AlbedoMap = i.uv_texcoord * _AlbedoMap_ST.xy + _AlbedoMap_ST.zw;
    			s6.Albedo = ( _BaseColor * tex2D( _AlbedoMap, uv_AlbedoMap ) ).rgb;
    			float2 uv_NormalMap = i.uv_texcoord * _NormalMap_ST.xy + _NormalMap_ST.zw;
    			s6.Normal = WorldNormalVector( i , UnpackNormal( tex2D( _NormalMap, uv_NormalMap ) ) );
    			s6.Emission = float3( 0,0,0 );
    			float2 uv_MaskMap = i.uv_texcoord * _MaskMap_ST.xy + _MaskMap_ST.zw;
    			float4 tex2DNode1 = tex2D( _MaskMap, uv_MaskMap );
    			s6.Metallic = ( tex2DNode1.r * _Metallic );
    			s6.Smoothness = ( tex2DNode1.g * _Smooth );
    			s6.Occlusion = 1.0;
    

    我们把Shader Graph转化成Shader脚本读起来还是比较简单的,学习起来也是容易的,关于次世代渲染技术就给读者介绍到这里。

    展开全文
  • DirectX实时渲染技术详解(第二版基于Direct9)含源码。
  • 《基于分布式架构的时空大数据分析系统时空大数据基础支撑软件》引入了高性能分布式渲染技术,搭建了基于分布式架构的时空大数据分析系统,有效解决了传统架构存在的海量数据入库慢、分析慢、分发慢、展示慢等诸多...

    地图服务发布是GIS应用系统的基本能力和要求,也是数据成果共享的重要方式。对地图服务提供者而言,关注重点一直是如何提供更高效、更优体验的地图服务。

    起初,地图服务发布一般采用动态出图的方式,但随着地图数据量的增加,在服务端动态出图需要花费的时间越来越长,超过可以在线等待的极限。于是,GIS产商通过预先生成地图的栅格瓦片来有效提升访问地图服务效率。

    然而,随着数据量的进一步飙升、需要查看的地图比例尺的进一步提升,大比例尺地图的栅格瓦片生成耗费的时间也越来越长。并且,若地图数据发生变化或者地图风格调整时,都需要重新生成栅格瓦片,更新非常不方便。

    为了更好的解决对空间数据越来越高的即时更新、即时发布、高效浏览的要求,超图通过引入大数据分布式技术,有效的整合了包括分布式存储、矢量金字塔、分布式渲染、自动缓存等一套高新技术,打造出高性能分布式地图渲染技术方案,实现基于HBase的超大规模数据的地图免切片发布服务,可以实现亿级空间数据:1)从拿到原始数据到完成数据入库仅需要数小时;2)无需预先缓存,数据入库即发布;3)地图动态秒级响应。下文将带您解密其中的关键技术。

    高性能分布式渲染的关键技术

    分布式存储技术

    分布式存储技术可以有效解决传统关系型数据库在超大规模数据管理方面的局限性。首先,关系型数据库很难应对单表亿级以上记录的查询和分析,而随着用户并发持续递增,硬盘读写也会成为一个瓶颈,特别是在扩展性和高可用性方面能力也比较弱,成本又相对较高。基于以上分析,关系型数据库已经很难满足大体量数据的存储需求。分布式数据库的分布式技术架构可以很好的解决上述问题。它可以实现横向扩展,通过集群的分布式处理方式对大数据量进行如水平拆分(将数据均匀分布到多个数据库节点中)的操作,这样相比较每个数据库节点的数据量会变小,相关的存储管理性能也自然提升。此外,主流的分布式数据库的分布式能力对用户透明,而且无缝顺应用户的SQL操作习惯,让用户在使用和管理上更加地简单便捷。

    经过选型,超图选择了HBase分布式数据库,HBase构建在HDFS之上,是一个开源的、分布式的、版本化的非关系型数据库。它的核心存储模型是基于Google的BigTable构建,目标是在廉价、可扩展的硬件设备之上,托管可以达到数十亿行和百万列级别的表对象。它具有模块化的设计,支持水平扩展和自动表分片,并且支持不同区域服务器之间的自动故障转移。

    所搭建的HBase集群可以注册到SuperMap iServer中,然后,使用iServer的“创建拷贝数据作业”功能,轻松完成本地UDB、GDB文件或shape文件以及已注册到iServer的数据库的数据导入到HBase数据库中,在研发环境中能够实现每秒11万条面对象的写入性能,为海量数据迁移到分布式存储中提供了坚实的保障。

    图 1:分布式数据入库效率的对比结果

    分布式渲染技术

    高性能分布式渲染技术支持免切片直接发布海量数据服务,那么,要保证大体量数据在Web端的快速响应,还要解决数据渲染性能的难题。为此,超图研发了分布式渲染技术,实现在iServer服务端,将请求的矢量瓦片的渲染任务分解,交由多个进程执行,更充分、更高效地利用计算资源;同时,还可以进一步配置iServer集群,将分块渲染任务发送给集群子节点分别执行,进一步提升计算的并行度。由此可见,这种多进程和集群的强强联合,极大地提升了渲染性能,实现超大规模数据的秒级响应效率。

    矢量金字塔技术

    上文的分布式渲染技术解决了超大规模数据高效渲染的难题,但对亿级数据在小比例尺乃至全幅显示时,仍旧很难做到秒级响应。因此,超图研发了矢量金字塔技术,它的设计思想类似于影像金字塔,通过对矢量数据进行多尺度分割,获得一系列以金字塔形状排列的数据精度逐步降低的数据集合。金字塔底部是矢量数据原始层级,而顶部是矢量数据的低精度近似表达。矢量金字塔技术解决了海量矢量数据在小比例尺秒级显示的难题,在保证显示效果的情况下,降低数据绘制的复杂度,从而大幅提升绘制性能。

    自动缓存技术

    自动缓存技术可以在以上技术支撑下,再进一步提升大规模高并发下的客户端地图访问效率。通过对用户浏览的数据进行无感自动缓存的方式,当再次浏览该区域的数据时,服务端无需再次渲染数据,直接显示缓存结果。

    高性能分布式渲染的价值所在

    高性能分布式渲染技术最值得推崇之处在于极大地缩短了从数据入库、数据处理到数据服务发布的周期,为行业应用赢得了效率。在高性能分布式渲染技术下,数据发布流程主要耗时在数据入库上,而地图服务发布是免切片的,所以切片耗时为零。下面的性能统计数据足以证明高性能分布式渲染技术完胜传统数据存储和服务发布模式。

    图 2:传统模式与新技术在海量矢量数据入库和发布流程的性能对比

    在高性能分布式渲染技术的支撑下,数据渲染效率显著提高,亿级数据在Web端具有良好的浏览体验;对于4.5亿线对象,约28亿节点的数据浏览,刷新一次的响应时间仅1秒。

    图 3:对HBase数据库中4.5亿线对象在客户端高性能动态渲染效果

    另外, 用户还可以进一步拓展应用系统的能力,实现在客户端直接进行数据查询、修改等操作,以及按照需求变更地图样式。

    高性能分布式渲染的系统架构

    了解了高性能分布式渲染的技术体系,确认它的确能够解决大体量数据的高效管理和服务发布的问题。那么,接下来您一定会考查这个高大上的技术如何部署到自己的行业应用中,如何实现现有应用系统的改造?下文将呈现一个清晰的系统架构和详细的部署方案。

    系统架构

    高性能分布式渲染系统的核心思想是系统的分布式架构。SuperMap全系列产品都已具备分布式能力,从数据的分布式存储到分布式计算,再到分布式的地图渲染,SuperMap产品提供了全方位的支持。下图为结合SuperMap产品的分布式系统架构图,具备了这样的系统结构,系统才能具备数据的高效入库和地图服务的高性能渲染能力。

    图 4:高性能分布式渲染架构

    系统搭建

    系统搭建的第一步为部署分布式计算集群,包括安装JDK,配置SSH及免密码登录,部署HDFS存储系统,部署zookeeper集群以及部署HBase集群。这里提供了快速部署环境的方案,您可以通过下面的二维码获取相关资料。

    图 5:快速部署环境的资料下载

    第二步,部署SuperMap iServer平台。

    第三步,基于SuperMap iServer平台使用HBase集群,进行海量数据的分布式入库,以及免切片发布地图服务。这里提供了详细的使用说明,您可以通过图 10中的二维码获取相关资料。

    图 6:(左)注册HBase数据库;(右)启动分布式分析服务

    图 7:配置多进程

    图 8:数据入库

    图 9:直接发布HBase数据为地图服务

    10 使用HBase集群进行数据入库的资料下载

    成功应用案例展示

    某单位的《基于分布式架构的时空大数据分析系统时空大数据基础支撑软件》引入了高性能分布式渲染技术,搭建了基于分布式架构的时空大数据分析系统,有效解决了传统架构存在的海量数据入库慢、分析慢、分发慢、展示慢等诸多问题。新的分布式架构获得了可观的系统运行效率:2400万个地类图斑入库仅需2.5h;提取金沙江流域500米缓冲带植被覆盖(植被覆盖图层1600万图斑)5分钟完成;植被覆盖图层1600万图斑,秒出图。

    图 11:千万量级数据的快速可视化

    图 12:数据高效查询与申请

    某省提供全省路况的地图服务,已有系统的地图服务发布是发布预先生成栅格瓦片,而对于路况地图服务,要求每5分钟对近一百万条的路况数据进行一次更新发布,显然预生成瓦片的方式将使路况服务失去了时效性,故而采用了高性能分布式渲染架构,省去了生成地图瓦片的时间,并且,新的架构有助于扩展分布式计算体系,进一步满足路况预测、路况推演、历史路况回朔等高效计算需求。

    图 13:全省路况实时展示

    某减灾中心建设地震灾区房屋监测系统,以指导应急工作。首先,该系统面向的数据来源较多,如灾区的矢量底图数据、房屋数据、实时烈度数据与震源数据、无人机及时获取的灾区高分辨率影像数据,以及采用机器学习技术基于高分辨率影像智能提取的矢量数据等,可见数据来源广、数据规模也极其可观。当灾害发生后,灾区的这些数据要能及时导入到系统数据库,并快速发布,还要保证千万级的数据在Web端和移动端能流畅地浏览。另外,在先进的数据采集技术的支撑下,灾区的数据也在及时更新,这也要求系统具有及时更新、发布海量地图数据的能力。减灾中心项目组选取了某灾区2000多万条受损房屋点数据,580多万条受损房屋面数据以及上万条实时烈度数据与震源数据,验证了一些方案,最终选用了超图的3节点HBase+iServer实现海量数据的高效管理与发布。

    展开全文
  • Unity PBR渲染技术系列一

    千次阅读 2019-10-01 19:36:22
    国庆假期终于空闲了,利用休息这段时间,把最近一直研究Unity的渲染技术成果给大家分享一下,目前,在游戏开发方面,两个职位比较火,一个是图形学程序,另一个是美术TA。这两个职位有个共同的特征就是需要掌握...
  • Direct3D实时渲染技术

    热门讨论 2009-07-23 23:54:54
    Direct3D实时渲染技术 Direct3D实时渲染技术 Direct3D实时渲染技术
  • 一些游戏用到的渲染技术

    千次阅读 2018-05-18 21:19:57
    泡泡网显卡频道2月19日 近年来3D图形技术的发展势头非常迅猛,软件方面游戏的画面和逼真度有了长足进步,硬件方面显卡的更新换代越来越频繁。但始终存在这样一个现象,无论显卡的性能翻多少倍,游戏玩家们总感觉还是...
  • 二次元卡通角色渲染技术概述

    千次阅读 2019-09-28 09:15:12
    好久没写博客了,最近一直在学习二次元卡通渲染技术,自从崩坏三,闪耀暖暖等二次元游戏出来后,作为程序员对他们使用的渲染技术很感兴趣,二次元卡通目前主要分为欧美卡通和日式卡通,我们以日式卡通为例给读者分享...
  • 基于服务器端的三维渲染技术

    千次阅读 2019-08-05 21:14:43
    Martin等人根据渲染发生在客户端还是服务器端,将三维渲染分为基于客户端的渲染,基于服务器端的渲染和基于混合端的渲染。 基于客户端的渲染 基于服务器端的渲染 基于混合端的渲染 渲染端 客户端 ...
  • 3ds Max_VRay 印象 灯光_材质_渲染技术精粹
  • 下一代3d渲染技术,体素光线投射

    千次阅读 2017-05-16 12:31:45
    下一代3D渲染技术:体素光线投射  在我们回顾一下光线跟踪之后,让我们继续概述可以取代的渲染技术,至少可以补充我们今天所知道的三角形光栅化。 阅读我们以前的文章的人已经知道了,我们并不真正相信实时光线...
  • 游戏开发相关实时渲染技术之体积光v0.1游戏开发相关实时渲染技术之体积光v0.1游戏开发相关实时渲染技术之体积光v0.1
  • DirectX实时渲染技术详解 GPU精粹实时图形编程的技术技巧和技艺 实时地形引擎(DirectX 9)
  • 3ds max 渲染技术课堂VRay应用技法精粹
  • 基于物理的渲染技术(PBR)系列一

    万次阅读 多人点赞 2017-03-19 21:54:20
    笔者介绍:姜雪伟,IT公司技术合伙人,IT高级讲师,CSDN社区专家,特邀编辑,畅销书作者,国家专利发明人;已出版书籍:《手把手教你架构3D游戏...PBR,或者用更通俗一些的称呼是指基于物理的渲染(Physically Based R...
  • 渲染技术的总结

    千次阅读 2015-10-03 13:00:56
    渲染在计算机图形学中是特别重要的环节,也是最能体现效果的,下面是我对渲染方面做的一些理论和技术总结,希望大家斧正。 渲染的定义:从模型生成图像的过程 本质上讲:渲染过程试图利用有限数目的像素将图像...
  • 游戏中的角色渲染技术之皮肤篇

    千次阅读 2017-06-21 10:18:20
    游戏中的角色渲染技术随着近几年来硬件机能的增长已经被大范围地应用在了各类AAA大作中,本文会取一些游戏为例,分类概述游戏中的角色渲染技术。由于整个角色渲染的话题会比较长,这个主题会用两篇来阐述,第一篇...
  • 渲染学校 探索渲染技术的魔力
  • VRay for SketchUp印象渲染技术精粹.pdf

    热门讨论 2012-06-21 15:54:29
    VRay for SketchUp印象渲染技术精粹TU201.4_369.pdf VRay for SketchUp印象渲染技术精粹TU201.4_369.pdf VRay for SketchUp印象渲染技术精粹TU201.4_369.pdf VRay for SketchUp印象渲染技术精粹TU201.4_369.pdf
  • 真实感水体渲染技术总结

    万次阅读 多人点赞 2019-12-08 21:06:48
    本文将对游戏开发以及电影业界的真实感水体渲染技术从发展史、知识体系、波形模拟技术以及着色技术等多个方面进行较为系统的总结,文末也对业界优秀的水体实时渲染开源库进行了盘点。     一、总览:水体...
  • 这是一篇近万字的文章,关于基于图像的渲染(Image-Based Rendering,简称IBR)技术的方方面面,将总结《RTR3》书中第十章提到的16种游戏开发中常用的IBR渲染技术。他们包括: 渲染谱 The Rendering Spectrum 固定视角...
  • 建筑装饰工程技术专业 教学资源库培训中心 软件技能培训 3DMAX...第12讲 渲染技术 12.1 渲染的基本常识 使用3ds Max创作作品时一般都遵循建模灯光材质渲染这个最基本的步骤渲染是最后一道工序后期处理除外渲染的英文为R
  • Unity水渲染技术

    千人学习 2019-07-06 12:28:12
    该课程主要讲解了两方面的内容:一是水的渲染,包括:水波动,水底焦散渲染,体积光渲染等等。二是海水编辑器的制作,实现了海边噪音,利用四叉树实现了海水网格的绘制等等。通过该课程的学习对与掌握海水绘制帮助...
  • D3D12渲染技术概述

    千次阅读 2018-08-22 09:27:03
    从D3D9到D3D12逐步提升,现在很多以前的引擎还是停留在D3...由浅入深,逐步讲解,不论做游戏还是做VR,AR都会涉及到渲染,很多公司会针对自己的项目封装一些图形接口用于渲染,掌握D3D12很重要的,回到正题,因为D3...
  • 非真实感渲染技术,其中包括水墨、卡通等不同的渲染技术的实现,基于GLSL。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 211,836
精华内容 84,734
关键字:

渲染技术