《BLAME!》是Polygon Pictures Inc.(以下简称PPI)创业33周年以来制作的第一部CG剧场电影,故事来自于贰瓶勉的同名漫画作品(中文译名为《探索者》或者《还特工次世代》)。也算是我本人来到日本之后参与制作的第一部长片。由于从头设计了流程,时间跨度约莫从2015年开始,以《Knight of Sidonia》为基本素材进行实验和改进,虽然中途发生了一些波折,也有许多地方的进步,但是最后终于如期发布。详情请访问blame.jp。制作细节就此逐渐公开发布。

因为在这里有一些革命性的手段,这些是日本动画业界,尤其是2D动漫业界没有想到过的方案,直接引入电影级别离线渲染的技术制作。听起来仿佛非常的广告用语,宛如培训机构的套话,其实如果展开来说,牵涉到了完全不同思路的问题。倘若你了解任何一家日本动画工作室,比如Oxybot、白组、Ufotable、anima等,制作流程上,思路上大同小异,使用Pencil或者mental ray制作基础的角色,使用特效软件比如Houdini制作特效部分,最后后期叠加。流程上说起来大同小异,但是实际运作起来,尤其是Lighting,思路上有巨大的不同。传统的方案,都是只用渲染器生成所有需要的Pass和Mask,然后进入后期软件中进行Lighting。对比真实动画的PBR流程,这种方案其实这个不能算是真正的Lighting,而且缺陷很明显。

  • 严重依赖于后期软件,分辨率受限,需要的时候无法立刻重置高清版版本。尤其是对于如今的VR来说,不好意思,如今的TV动画,放大了之后在人的眼里都是锯齿。如今的OVA,都是放大上去的高清,其实谈不上高清,只是分辨率高了,模型锯齿什么的,都完全的清晰可见。
  • 10年前开始推行电影3D技术,发明了Multi Camera Rendering,如今有了VR等等更多的渠道。那么答案显然易见,你只有选择合适的工具才能实现。这一点只有电影级工具才考虑了这么多未来需求,纯粹的动漫技术都是非常低级的。
  • 后期占用大量的存储空间、处理时间。因为在Nuke里进行复杂场景的合成与渲染,一定比直接从Maya里渲染Single Beauty还慢。这一点在本片的制作中得到了充分的证明。
  • Pencil、mental ray这些软件在处理几何体上远远不如影视级别渲染器,对比3Delight、PIXAR RenderMan、Arnold等等。这样极大的限制了几何体的细节丰富程度,所以一定无法在有效的成本之下制作高度复杂的场景。
  • 渲染上非常受限。归纳起来所有的工具链,无论是mental ray、Pencil、PIXAR RenderMan等等,要么只能做NPR,要么只有PBR,而且没有提供完整的功能合集,可以横跨两个领域。对于未来作品艺术上的拓展性也就是个巨大的限制。

上传图片的方法

这个项目完全使用了3Delight。由于和DNA Research的良好合作伙伴关系,在制作过程中由于NPR的一些特殊需求,我们直接得到了3Delight的内部支持,一起合作添加一些NPR渲染才需要的功能,比如革命性的可编程边缘检测(Programmable Outline Detection)。这一点在任何的渲染器中都不曾有过。在Look Development的过程中,我们引入了物理真实感渲染中的一些概念,比如

  • 卡通次表面散射(Tone Subsurface Scattering)
  • 物理级正确的透明勾边(Physical-Corrected Transparency Outline)
  • 完全程序化生成的眼睛(Procedural Toon Eye)
  • 完全程序化生成的卡通头发(Procedural Toon Hair)
  • 前期生产配合统一的完全可视化的卡通调色方案(Unifield Visualization System for Color Palette/Script)

制作上可以说可以完全抛弃手绘的参与,一切都用机器生成的思路进行。这些是匠气浓郁而轻视技术的传统日本动画流程中所绝对不敢想的功能,极大的丰富了画面的感觉,也提高了流程的的效率。特别需要提到的是完全程序化的眼睛和头发,完全更改了以往的制作方式,使得更加的可控,可以快速的生成任何角色的效果,彻底的程序化控制,摆脱人力多层绘制,再来生成贴图这种低效率的方案。最后一项配色方案,可以说彻底的颠覆了日本动画30年来对“调色盘”的概念,可以保证在后期软件中进行设计的结果,克服了经典的调色盘系统,可能存在返工,修改周期长成本高的缺点,可以做到直接和Beauty渲染的颜色上完全一样,让前期与后期完美的统一。

由于3Delight对原生RenderMan的良好兼容(讽刺的是PIXAR倒是完全放弃了RenderMan的老标准),这里完全是使用的RenderMan Shading Language,即RSL进行的制作。可能一些CG从业人员会认为RSL已经老去已经过时,其实此言完全诧异。就有的RSL,由于比较的底层,可以访问照明循环(复习一下illuminance()和RenderMan的Message Passing,都是多么强大实用的生产级别功能),可以随意的发起任意的渲染操作(trace、gather),提供最丰富的函数支持,所以对于混合渲染(Hybrid)来说,是最具灵活性的方案,可以任意的切换GI与NPR的组合,可以随意的对物体的渲染结果进行控制。这一点,其他渲染器的Open Shading Language完全无法做到,因为一切都变成了渲染器的内部逻辑,用户不再可控。非专业用户会认为OSL比起RSL具备多少革命性的优势,那么我可以很坦然的说,从JIT代码生成的角度来看,无非就是OSL使得用户把一部分逻辑代码内植入了渲染器本身,而不是让用户自己控制。其他的SIMD代码生成,可以说并无任何区别。当然对于Shader开发来说是极大的简化,其实也是极大的限制,这一点不是所有人都能够意识到。3Delight可以做到,因为是完全自己制作的OSL后端,并且拓展了OSL语言本身的功能,这一点SIGGRAPH 2016之后大家都会看到。

开始说本片的缺陷部分。提前声明,这个片子的制作,我们只提供渲染和制作方案,具体的生产还是日本人定夺,具体的效果在我们控制之外,不是我(们)的责任。

而且这里要是以为核心竞争力在于用什么软件,比如这里我反复提及的3Delight,那么你就错了。因为传统动画从业人员,包括数以亿计的动画爱好者,本身并不是专业出生,倘若深刻的理解了计算机编程图形学等等,这才是万里长征第一步,还得深刻的理解生产,和知道为了实现效果所牵涉的所有技术和可能出现的问题,这个时候就完全脱离了软件本身的范畴。多年来国内动画行业贯彻的那一套思路和教育方法,学软件,买软件,用软件,做出来的东西,无论是《熊出没》还是《爵迹》,更不提各种国产港产特效电影,技术上艺术上都是双重垃圾,绝对达不到国际竞争力的可能。当然这个话题很远了,就此打住。

日式动画=主角+简单的特效+背景,这种模式已经走到了穷尽,一定无法适应未来的需求。看一下手绘的背景,多么的粗糙,毫无动态性可言。如果是电影级别的方案,联系到这样的一个机械城市题材,那么一定存在大量的Procedural,一定是在镜头中,观众可以感知场景的动态变化,而不是黑乎乎的背景,然后利用景深来掩盖低分辨率的事实。所以这个动画的角色部分过于精细,而其他元素显得粗糙,是一个非常显然的缺陷。当然这个是日式所有动画产品的缺陷,过度依赖角色和故事以及剧情,场景元素上非常的单一,其实并不是日式的特色,而是对缺陷和能力的掩饰。

那么很显然的,当场景元素特别多,比如需要渲染一个城市的时候,这个时候固守残缺的工具链都无法使用,技术级别一定向着电影级靠拢。这个其实日本人整体电影工业都做不到,所以对于动画也就不能指望达到。所以这个限制也来自于工具——比如mental ray渲染Subdivision多么的耗费内存,速度多么的慢,想必任意一个当年用过RenderMan和mental ray的人,都知道哪一个才是真正的可行方案。记得去年SIGGRAPH Asian 2015 Kobe,有一个特殊的会议,日本的动画公司聚在一起讨论,如果未来没有了mental ray怎么办,还希望Autodesk做一些事情。那么答案是显然易见的,Autodesk绝对不会理睬这群低端客户,当然也不会继续维护mental ray的插件。

再来,没有表现好材质,尤其是这种金属高科技材质,高反射率金属。当然在传统的动画中,这个是被忽视的,或者说是没有这种印象的,一切都是高度的Diffuse,一切都是Clamp/Step。这个其实主要是艺术导演的守旧所致,因为存在Step+Realistic的最佳组合,而在这部片子中除了主角Killy的皮衣,其实就是3D Diffuse加上的Rim Light,其他的都是Clamp。当然如果是为了照顾2D Anime的风格,这个主角的脸、眼睛、头发这些元素可以遵守风格,但是其他的材质显然可以大幅度的提升。

插曲:《BLAME!》制作流程的选择经历了太多的波折,感觉上可以用无奈来形容。“我们”是一个完全说英语的外国人的技术团队,由于PPI的CEO是非常具有国际化眼光的职业管理人,聘用了我们做为独立的研发团队,让我们与本土的日本人合作,也就是你在最后看到的那些头头脑脑,导演总监之类的。当我们直接一眼看穿了他们旧的流程,开始展示全新的技术和潜在的可行性的时候,日方制作人极力的否认优势,极力的用不专业的理由判断来强词夺理,其实只是维护自己的面子。说实话,日本动画行业的CG Supervisor,论能力,全球行业来看只相当于高级美工高级艺术家,对于他们在艺术上的能力,对画面的把握,我是持肯定态度的,但是毛病也是和国内的CG业界人员甚至游戏行业的行为一样——认为自己所不完整理解的技术是素质的核心,为了面子以及推脱责任否认自己无法意识到问题的根本。但是除此之外,没有艰深的知识储备,也做不到指导生产的能力,所以也不能指望革命性的提高产品的素质,因为知识系统和做事的方法都不具备竞争力。

非常欢迎国内图形学届和动画游戏行业的朋友一起探讨,我也在积极的寻找合作的机会,共谋本土大业。

联系我们

  • http://j-cube.jp/
  • bo.schwarzstein@gmail.com
  • support@j-cube.jp

从《BLAME!》说开去——新一代生产级卡通真实感混合的渲染方案的更多相关文章

  1. 从Linux内核升级的必要性说开去

    Linux内核更新超级频繁,可是有必要时刻升级吗?个人感觉没有必要,可是你要时刻关注新特性列表,然后把自己的内核升级到离最新版本号差一两个月公布的版本号而不是最新版本号.以保证稳定性,由于一两个月的时 ...

  2. 使用 Sealos 在 3 分钟内快速部署一个生产级别的 Kubernetes 高可用集群

    本文首发于:微信公众号「运维之美」,公众号 ID:Hi-Linux. 「运维之美」是一个有情怀.有态度,专注于 Linux 运维相关技术文章分享的公众号.公众号致力于为广大运维工作者分享各类技术文章和 ...

  3. 微信自研生产级paxos类库PhxPaxos实现原理介绍

    转载自:   http://mp.weixin.qq.com/s?__biz=MzI4NDMyNTU2Mw==&mid=2247483695&idx=1&sn=91ea4229 ...

  4. 【分布式事务】基于RocketMQ搭建生产级消息集群?

    导读 目前很多互联网公司的系统都在朝着微服务化.分布式化系统的方向在演进,这带来了很多好处,也带来了一些棘手的问题,其中最棘手的莫过于数据一致性问题了.早期我们的软件功能都在一个进程中,数据的一致性可 ...

  5. Java全栈程序员之07:IDEA中使用MAVEN构架生产级的Web项目

    在上一篇我们介绍了如何在IDEA中使用MAVEN,以及如何创建依赖等.那么在这一篇中,我们就试图搭建一个生产级的解决方案,大家可以使用这个解决方案作为骨架代码来搭建自己的开发环境. 在这里,我们要完成 ...

  6. [Objective-C] 从NSInteger说开去

    在iOS开发过程中,我一直习惯于使用C语法里的基本类型,而很少用(除非必须使用)Foundation的数据类型.最近看了一些资料,发现自己这样写可能有风险,虽然目前没遇到过相关的问题,但这是非常需要注 ...

  7. (转)2019年 React 新手学习指南 – 从 React 学习线路图说开去

    原文:https://www.html.cn/archives/10111 注:本文根据 React 开发者学习线路图(2018) 结构编写了很多新手如何学习 React 的建议.2019 年有标题党 ...

  8. Kubernetes 1.14发布:对Windows节点的生产级支持、Kubectl更新与持久本地卷通用版本已全面到来

    今天,我们高兴地宣布Kubernetes 1.14版本的正式亮相,这亦是我们在2019年当中进行的首次发布!Kubernetes 1.14版本由31项增强功能组成,具体包括:10项稳定版功能,12项b ...

  9. 使用AWS、Docker与Rancher提供弹性的生产级服务

    2017-07-26 开始想你的 RancherLabs AWS Summit 2017 Beijing已经圆满落幕啦!亚马逊公司首席技术官沃纳·威格尔博士莅临现场,分享 AWS 最新云解决方案,把握 ...

随机推荐

  1. js之文档对象的设置(DOM)

    1.对象文本: 对象.innerHTML;   对象.innerHTML=""; 对象.innerText; 对象.innerText=""; 2.对象属性: ...

  2. checkbox和radio使用

    jQuery获取Radio选择的Value值: jQuery   C#   VB   C++   Java jQuery设置Radio的Value值: 语法解释: 1. $("input[n ...

  3. EditText的hint不显示

    EditText的hint不显示可能的原因: 1.字体颜色与EditText的背景色一样; 2.使用了android:inputType = phone; 3.如果加上android:ellipsiz ...

  4. JS实现滑动门效果

    html部分 p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 31.0px Consolas; color: #2b7ec3 } p.p2 { margin ...

  5. 如何使用grunt工具

    本文来源于同事的笔记,也是在网上查找的资料,记录分析的特别详细,对初学者来说简直不能再通俗易懂了,感谢原作者! 1.前言 选择Grunt原因 管理我们的文件依赖 随心所欲的批处理任务 整合常用的前端工 ...

  6. log4j2自定义输出线程环境信息

    在配置日志的输出格式的时候,我们可以按照内置的规则输出日志,但是有时候需要及时输出我们自定义的信息,这时需要借助ThreadContext类. ThreadContext类类似于MDC和NDC,它是一 ...

  7. 将特定TD颜色改变的两种方法

    方法一:取table值 方法二:使用tbody  

  8. JQuery学习(选择器-基本-*)

    <%@ page language="java" import="java.util.*" pageEncoding="UTF-8"% ...

  9. Incompatible operand types DeptE and int 异常处理

    Incompatible operand types DeptE and int 1.java不会运算到==的值,把==改为equals 2.java不会运算到eequals的值 把equals的改为 ...

  10. 《Linux内核设计与实现》读书笔记(十六)- 页高速缓存和页回写

    好久没有更新了... 主要内容: 缓存简介 页高速缓存 页回写 1. 缓存简介 在编程中,缓存是很常见也很有效的一种提高程序性能的机制. linux内核也不例外,为了提高I/O性能,也引入了缓存机制, ...