zoukankan      html  css  js  c++  java
  • GDC2016 执着于光影表现的【全境封锁】的开放世界渲染

    执着于光影表现【全境封锁】的开放世界渲染

    Snowdrop(雪莲花)引擎的全局照明技术介绍
     
    补上原文链接:http://game.watch.impress.co.jp/docs/news/20160322_749267.html
     
     
    UBI MassiveスタジオのNikolay Stefannov氏
    UBI Massive 工作室的Nikolay Stefannov
     
        3月18日,UBI Soft的技术主管Nikolay Stefannov进行了题为【Global Illumination in 'Tom Clancy's The Division'】(全境封锁的全局照明技术)的Session。
     
        在家用机和PC游戏的世界,GI已经变得习以为常了。既然GI已经是必须的话,那就要以现今有效的GI光照为前提,并向有一定风格的【画面制作】的焦点转移。画面制作,并不仅仅是美术师在数据绘制上的方法,还有程序上的技术。这里,Stefannov就是以【全镜封锁】画面制作的技术方面进行了解说。
     
     【游戏世界中光源的移动变化】

     
        【全境封锁】,是UBI的瑞典工作室UBI Massive开发的第三人称射击游戏,引擎使用的是UBI自研的雪莲花引擎。【全境封锁】有着RPG元素,游戏场景变成了开放世界。以纽约曼哈顿的6平方公里为游戏舞台,世界内有有着总计200万的实体(物体对象)。车辆总数约2万量,垃圾堆3万座。
     
        因为要重视开放世界的整体性,光照为了强调美术师的演出意图,在项目上做了限制,日光无法照明到所有的空间,经常有发暗的地方。
     
        雪莲花的GI光照,因为全部都是动态的,什么时候都可以进行调整。为了提升性能,很多的游戏引擎通常会把光源的影响的预计算结果烘培到光照贴图里。而本作的雪莲花引擎,最大的特征就是完全的动态光照。使用的Light Probe,因为管理太复杂,也并不太适应项目的设计。
     
    【本作技术的核心特性】

     
     GI的影响范围不仅仅是室外。本作中,为了系统可以不区分室内和室外,在室内也会有很大的开口让真实的光照射入,根据游戏世界里时间的变化,光影的色彩也会改变。室内的家具,虽然不是全部,也作成受到光照的影响。为了可以利用这种空间光照的特性,不能生成光照反射。
     
        气候的动态变化是通过脚本随机的变化的,包括太阳和天空的颜色,云的多少,雾和霞的强度等等。还有程序化实现的降雪系统,使得本作的场景变得更加的突出。
     
     
    【PRT ON/OFF的比较】

     
     
        要实时的进行这种动态的光照,通常在没有光源变化的场景中,使用预先计算出光源影响的Precomputed Radiance Transfer(PRT)的方法,一般的PRT,Porbe检测的HDR环境光,只能处理Directional light这种有方向性的光。用这种光照方法,无法获得想要的结果。另外,即便是高频的也可以使用PRT,不过计算消费太高了。
        
        那么,本作中的蛮力方法,是近似GBuffer CubeMap的方法,预先检测出所有可见的物体表面保存为列表数据。 Light Probe自定的配置为4米的空间,64米的四方区域(Cell)里最多有1000个这样的Light Probe,通常是200~300个。区域会对应玩家移动来读取或销毁(Streaming),从而可以绘制整个广阔的开放世界。
     
    【 全局照明技术的方法解说】
     
     
     
        每个区域(Cell)制作预处理数据大概要5~6秒,通过这个计算结果得到的曼哈顿的光照数据资源大概是1GB的硬盘空间,区域总数约4000个,Probe约116万,物体表面5664万。
     
        使用这些数据,在游戏运行时再每帧进行光照的计算。本作中,不同的Probe Set之间的结果没有做混合。这是因为需要短距离的GI效果,也算是本作的特征吧。
     
        这种光照的在计算在性能上,每帧会对玩家所在的区域和另外的一个区域进行处理,每次处理800~900个Probe,在Xbox One上异步0.95ms,GTX760的PC上是0.47ms,在维持高帧率的同时获得了非常好的效果。
     
    【游戏内移动变化产生的光照变化】
     
     
     
        上面记述的主要是本作的GI方法。本Session中,还介绍了很多游戏中采用的提升图形品质的方法。每个都是比较熟悉的方法,不依赖通用的游戏引擎,而开发公司自己的引擎,就可以使用最合适的技术来制作来完成自己的画面制作了。
     
        UBI和EA的各个工作室的情况是,强力的工作室会制作公司自研的引擎,进行改良,并在几个工作室内共享。这样才能满足游戏所需要的技术力,并运用到更多的游戏上,达成更高的销量吧。
     
        在越来越多采用第三方的游戏引擎的现今,我想可以有这样的决断是相当难得的,不过为了画面制作的多样性,还是希望有技术和实力的工作室可以继续这个方向。
     
  • 相关阅读:
    对象关系一对多转换为一对一的方案——中介者模式总结
    接口转换的利器——适配器模式总结
    多线程场景设计利器:分离方法的调用和执行——命令模式总结
    对比总结三个工厂模式(简单工厂,工厂方法,抽象工厂)
    创建多个“产品”的方式——工厂方法模式总结
    Java反射+简单工厂模式总结
    最简单的设计模式——单例模式的演进和推荐写法(Java 版)
    对复合(协作)算法/策略的封装方法——装饰模式总结
    Java对象序列化全面总结
    创建产品族的方式——抽象工厂模式
  • 原文地址:https://www.cnblogs.com/TracePlus/p/5314481.html
Copyright © 2011-2022 走看看