blenderdiplom訪談 – Ken Museth on OpenVDB

Ken Museth

Ken Museth

Ken Museth與blenderdiplom的訪談,看看在Ken Museth的帶領OpenVDB的團隊開發一個OpenSource的Library的目的與未來的發展。

譯者:renderloop

原文連結
http://blenderdiplom.com/en/interviews/574-interview-ken-museth-on-openvdb.html

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。

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)和破碎並非直接但卻間接和容積有關係。你可以使用容積資訊做碰撞偵測以避免物件穿插。另一個例子則是使用容積資訊做各類型的算圖應用。總而言之,視覺特效部門非常仰賴容積資訊。

它可以用來做清除模型的交集(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這資料結構本身是有一點複雜,我們僅有少數人曾針對這部分做過編修貢獻,我想這是因為它複雜到有點嚇人的緣故。直接去了解並使用此資料結構,並不是容易的一件事。而我們獲得的大多數編修貢獻,主要來自於建構在此資料結構之上的工具程式,當然這也是非常非常有幫助。

OpenVDB可以儲存大量不同屬性的體積資訊

OpenVDB可以儲存大量不同屬性的體積資訊

BD: 請問這次開放原始碼的過程是艱辛的嗎?

Ken: 當然! OpenVDB 是 Dreamworks Animation 第一項且是目前唯一的開源計畫。幾乎花了整整兩年才獲得批准。大家一路上都非常支持,我們未曾碰過窒礙難行的情況,但過程花了法律部門相當多的時間去審視。第三方應用整合是主要的賣點。事實上SideFX應允支援我們的開發工作對這方面有著極大的幫助。

BD: SideFX 是從一開始就參與OpenVDB的協作嗎?

Ken: 是的,我們和SideFX的開發人員密切地合作,他們會審視我們的程式碼並提供修正的建議。這是非常緊密的協作關係。

BD: 你希望看到那些第三方應用程式採用OpenVDB?

Ken: 舉例來說,我們希望它被整合進Maya,同時也樂見被Blender所採用。我們希望看到OpenVDB被應用於這兩大主要的第三方專案。我們針對Maya有一些基本的支援,實際上已開放幾個Maya節點(nodes)實作,但我們內部並不常使用Maya來製作容積特效,所以我們希望開源社群中會有人接手這部分的開發工作。

BD: 你目前是否有計畫將OpenVDB移植到GPU架構上?

Ken: 那是很好的想法。但我們目前尚未排定計畫,而且移植工作也並非全然直觀明瞭。OpenVDB過去針對CPU架構做高度最佳化,但GPU是一個徹底不同的硬體架構。這不是一項容易的工作,但無疑是一個非常有趣的方向。我們過去曾和NVidia接觸,他們告訴我們他們在移植的部分已有初步的成功結果,但我猜我們在實作面必須做許多相關變動。我們公司內部有一個GPU的算圖工具算是有某種程度的相關支援,但它主要是在把資料讀進顯示卡記憶體前,將OpenVDB的資料結構轉換至一個階層化的資料框格(tiled grid)。
簡單的答案是: GPU架構的支援工作是我們會去關注的方向。

在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 所有

render.loop

3D 圖學愛好者,平日以『找論文、看論文、寫程式』維生,喜歡討論關於計算機圖學的兩三事。

Comments are closed.