【行业资讯】OpenVDB团队Leader Ken Museth访谈

17 十二月, 2014
140
0

Ken Museth on OpenVDB -1
Ken Museth与blenderdiplom的访谈,看看在Ken Museth的带领OpenVDB的团队开发一个OpenSource的Library的目的与未来的发展。

译者:renderloop

OpenVDB尚未出现在Blender之中,但目前Blender已有计画将其整合进未来的版本。你可能会感到好奇,OpenVDB到底是什么? BlenderDiplom 这次和Dreamworks 内负责OpenVDB开发项目的首席工程师Ken Museth,谈谈这项软体专案以及使用者可以对一个应用OpenVDB的软体有什么样的期望。
BD: 哈啰,Ken。现在你正任职于Dreamworks,请问你在公司内实际的工作内容为何?你负责的专案是什么,还有你在OpenVDB中所参与的部分为何?
Ken: 我从2009年开始在Los Angeles的Dreamworks Animation工作。我是特效研发总监(R&D VFX supervisor)和资深首席工程师(senior principal engineer)。我负责一个研发制程工具的研究团队,同时我自己也是一位软体开发人员。我参与VDB的部分? 嗯,我是在2009年发明了VDB并发表相关研究成果。它陆续被改良且公开于2011年的SIGGRAPH大会。我们团队的核心要务是负责维护、扩展和发布OpenVDB。
Ken Museth on OpenVDB 1-1

OpenVDB 拥有meshing 系统OpenVDB 拥有meshing 系统

BD: 作为一般使用者,你可以从那些支援OpenVDB的应用程式中期待什么?
Ken:让我们先看看那些开发者已应用多年且常在第三方应用程式中出现的容积(volume)架构。使用者先建立一种立方体的结构,而模拟的效果则被限制在立方体所包围的范围内,那些通常是所谓的密集晶格(dense grids)。立方体的尺寸对于计算过程所需的记忆体用量有着巨大的影响。当你提高立方体的解析度时,其内部使用voxel数量会越来越多。一个voxel可以类比为一个三维像素(pixel)。所以问题便是那些密集晶格需要相当多的记忆体。而VDB则是让你抛开外围立方体的限制,让你用一种更节省的方式去储存内部的资讯。对于软体使用者而言,这意味着可以再提高那些烟、火或是水的模拟细节。而对于流体模拟的应用程式而言(尤其在模拟资讯储存分布是稀疏的情况下),VDB会是一个非常好的选项。 OpenVDB已自2012年整合至Houdini,所以若你使用的是12.5或之后的版本,那你正是使用内建的OpenVDB。
大多由特效部门制作的效果都牵扯到容积(volumes)。典型的效果像是动态的沙尘、烟雾、水、火、甚至是破碎(fracturing)。许多效果像是刚体动力学(rigid body dynamics)和破碎并非直接但却间接和容积有关系。你可以使用容积资讯做碰撞侦测以避免物件穿插。另一个例子则是使用容积资讯做各类型的算图应用。总而言之,视觉特效部门非常仰赖容积资讯。

Ken Museth on OpenVDB 1-2

它可以用来做清除模型的交集(intersection)它可以用来做清除模型的交集(intersection)

BD: OpenVDB 目前被应用于许多第三方工具和算图软体(renderers)。
Ken: Arnold 已透过外挂(plug-ins)的形式支援,此外也有对于Pixar Renderman的支援。 Realflow底层也有使用OpenVDB。非常多应用程式使用OpenVDB。这也是Dreamworks决定开放原始码的主要动机之一,所以这些公司可以帮我们做应用程式整合的工作,让我们有更多的时间去做其他开发。一般人并不知道我们花了大量的时间去将此技术整合至现有的制程(pipeline),像是开发使用者介面、脚本语言对应和其他支援。这些工作花费相当多的时间。有了其他公司的协作,帮忙处理这些工作,我们得以将时间专注于OpenVDB的改进上。我们发现因为有着SideFX的整合与维护,我们拥有更多的时间去从事我们真正的要务─即是将此技术做进一步的提升。
BD: 这是将你们的原始码开放的好处之一,那么缺点会是什么呢?
Ken: 缺点之一是耗时。大量的时间都花在维护储存库(repositories)、建置系统、撰写文件和其他类似的工作。同时也有许多来自开源社群的压力。我们接到许多关于新功能的请求,典型的需求像是『为何你们不支援Windows平台』你总是必须去在这些请求和Drewmworks内部的需求之间做取舍。举例来说,因为Dreamworks内部使用的是Linux平台,所以较没有特殊的动力去支援Windows上的开发工作。但我们还算幸运,因为SideFX的产品支援Windows平台,所以这工作是由他们在处理。处理这些外部压力实际上是耗时的,这算是开放原始码的一部分缺点。但这些缺点瑕不掩瑜,如同我之前提到的,首要的优点是应用整合,事实是我们不需要去支援所有工具的整合工作,因此我们有更多的时间去进行其他开发。
我们发现的另一项优点是,开放原始码是一种非常好的方式去和其他电影工作室及学界研究人员进行协作。实际情况是我们有一个软体,任何人都可以使用并做出贡献而没有智慧产权方面的问题,这对协作相当有益处,且我们已多次整合过外部开发者的程式码贡献。有些时候学术研究社群会使用VDB当作研究开发的基础,而一些他们的研究想法也有可能会反过来被整合进来,我们也曾经和其他工作室有过几次这样的经验。
BD: 在两年前的FMX会议中,另一项受欢迎的VFX开源计画的首席工程师曾说,相较于内部开发,开放原始码并不一定较节省成本,但也不会更为昂贵。请问你对于这方面直观的想法为何?
Ken: 我想我会同意他的说法,开放并不会更昂贵。但更重要的是,开放原始码提高了品质的标准! 公开程式码的品质远优于那些针对内部开发的程式码。你和全世界共享程式码,每个人都可以看你的成品,这是提升程式码和文件品质的巨大驱动力。良好编写的程式码、说明文件和简洁的API会使得专案维护的工作较简单。
BD: 这正是Larry Gritz告诉我们关于开放OSL(Open Shading Language)的经验。他同时提到开放原始码让开发者面对使用群众。像是收到一堆电子信件之类的,请问这是好、还是不太好呢?
Ken: 正是如此! 坦白说,我们在计画一开始前并没意识到,但这的确让我们感到惊讶,是令人非常愉悦的那一种惊喜。曾有Dreamworks的开发者看着OpenVDB的原始码,然后告诉我们说这是他们在公司内看过最简洁的程式码,而这正是我们想要达成的目标。
BD: 你们有从外部获得大量赞美或是更多批评吗?
Ken: 我想OpenVDB的问题之一是使用大量metaprogramming的技巧来实作。尽管已有详尽的文件记录,但若是你不熟悉这类型的编程技术的话,在看程式码的时候会较难去了解与追朔。实际上,关于VDB这资料结构本身是有一点复杂,我们仅有少数人曾针对这部分做过编修贡献,我想这是因为它复杂到有点吓人的缘故。直接去了解并使用此资料结构,并不是容易的一件事。而我们获得的大多数编修贡献,主要来自于建构在此资料结构之上的工具程式,当然这也是非常非常有帮助。Ken Museth on OpenVDB 1-3

OpenVDB可以储存大量不同属性的体积资讯OpenVDB可以储存大量不同属性的体积资讯

BD: 请问这次开放原始码的过程是艰辛的吗?
Ken: 当然! OpenVDB 是Dreamworks Animation 第一项且是目前唯一的开源计画。几乎花了整整两年才获得批准。大家一路上都非常支持,我们未曾碰过窒碍难行的情况,但过程花了法律部门相当多的时间去审视。第三方应用整合是主要的卖点。事实上SideFX应允支援我们的开发工作对这方面有着极大的帮助。
BD: SideFX 是从一开始就参与OpenVDB的协作吗?
Ken: 是的,我们和SideFX的开发人员密切地合作,他们会审视我们的程式码并提供修正的建议。这是非常紧密的协作关系。
BD: 你希望看到那些第三方应用程式采用OpenVDB?
Ken: 举例来说,我们希望它被整合进Maya,同时也乐见被Blender所采用。我们希望看到OpenVDB被应用于这两大主要的第三方专案。我们针对Maya有一些基本的支援,实际上已开放几个Maya节点(node​​s)实作,但我们内部并不常使用Maya来制作容积特效,所以我们希望开源社群中会有人接手这部分的开发工作。
BD: 你目前是否有计画将OpenVDB移植到GPU架构上?
Ken: 那是很好的想法。但我们目前尚未排定计画,而且移植工作也并非全然直观明了。 OpenVDB过去针对CPU架构做高度最佳化,但GPU是一个彻底不同的硬体架构。这不是一项容易的工作,但无疑是一个非常有趣的方向。我们过去曾和NVidia接触,他们告诉我们他们在移植的部分已有初步的成功结果,但我猜我们在实作面必须做许多相关变动。我们公司内部有一个GPU的算图工具算是有某种程度的相关支援,但它主要是在把资料读进显示卡记忆体前,将OpenVDB的资料结构转换至一个阶层化的资料框格(tiled grid)。简单的答案是: GPU架构的支援工作是我们会去关注的方向。

Ken Museth on OpenVDB 1-4

在OpenGL使用GPU做即时显示OpenVDB的资料在OpenGL使用GPU做即时显示OpenVDB的资料

BD: 你还有什么其他针对OpenVDB的计画? 储存粒子资料(particle data)的资料结构会是其中之一吗?
Ken: 是的,粒子资料是我正在推动的一项大计画。在即将上映的『驯龙高手2』的制作过程中,我们面临到将大量粒子资料(像是三亿颗粒子)转换到VDB的问题,我们发觉目前拥有的工具无法有效解决此问题。因此我们开始找寻可以将粒子资料储存在相同树状资料结构的方式,后来我们在这部分也获得显著的成功。在今年夏天的SIGGRAPH大会上,我们希望在将其当作OpenVDB 3.0的一部分而公开。这同时也是一项有趣的计画,因为这是我们第一次正式与其他工作室协作开发。一位来自Double Negative的研究员将会过来与我们合作。
这大概是我们目前最大的开发计画,但我们同时关注细节层次(level-of-detail)。所以我们尝试着去找出如何储存不同解析度的容积资料,这样算图软体就可以根据与镜头的距离远近去选择适当的资料解析度。
我们也想要有云的建模工具,同时我们也正在研究记忆体超载(out-of-core)的读取技术。 VDB会管理延迟读取的时机,所以当从算图软体发出的光线射到不同的空间区域时,它仅会读取周遭相邻部分的资料,而非将所有的容积资讯读进记忆体。
BD: 从记忆体使用量的角度来看,你认为使用GPU算图在未来会是可行的吗?
Ken: 基本上,我们处理的容积资料很少超过几GB,所以只要你的显示卡有足够量的记忆体,那应该是可行的。
BD: 那关于分散式网路算图的技术呢?
Ken: 我们考虑过此事,但这并不是我们在Dreamworks通常使用的机制。我们有一个算图农场(render farm),但每一个计算核心都拥有完整场景的副本。我想OpenVDB可以应付此类型的算图机制,因为它是使用一个阶层化资料框格(tile grid),末端节点(leaf node)可以被分配至许多不同的电脑。我曾听说有一间公司实际应用此概念到液体解算器上(liquid solver),他们回报说这是有效的解决方式。
BD: 你认为目前在Dreamworks内部,是否有其他任何一项开发专案会从开放原始码中受益?
Ken: 我们讨论过一些专案,但我想其中没有任何一项是正在制程上运作的专案。过去曾有一些讨论是关于在OpenVDB之前,先启用一个专案当实验测试。我并不知悉内部有任何即将开放的软体专案,但在OpenVDB的成功经验下,若有任何其他开放原始码的计画陆续开启,我也不会感到意外。

所有的文章内的图片版权皆属Dreamworks Animation 所有