renderman

Bernard Edlington 在他的 blog 上發起了一個 RenderMan community of Japan 的活動，主要就 RenderMan 技術上的討論，目的在日本推廣 RenderMan 這個東西，同時匯集身在日本，使用 RenderMan 的人。同時，他還預計在今年的 SIGGRAPH 2008 期間，在 LA 進行第二階段的活動，讓旅外的日本人也有機會參與到。

我只能說，他相當的用心吶…

有趣的是，他好像是一位外國人，但是他的 blog 有好多日文呀 :o

故事是這樣的。

因為遇到了個小問題，於是跑去 RenderMan 官方的支援網站問，然後官方一位「常態性回覆官員」出現，先問了我是用 RenderMan Studio (RMS) 還是 MTOR 7.0，然後說我的問題可能沒好的解決方案喔。結果官方的另一位「感覺起來，比較資深的官員」跟著出現，他澄清了一下，我的那個小問題，不管是 RMS 或是 MTOR 都可以用同樣的小撇步解決，因為關鍵程式 it (Image Tool），在兩者之下，運行起來是一模一樣的。

下頭是這一位官員的回覆：

Sure. Its part of it, not RMS. It gets run from "it" for any render that is send to, well, it.
You set the post render script in the "it" settings that ian described.

(Note to self, never name a software product "it")

看官你有辦法看出來，這段回話裏頭，每個 it 各是指什麼嗎 XD

這應該是我使用 Pixar's RenderMan 以來，看過最落落長的一個 rendering job 了。粗略地算了一下，有 300 個左右的 task，且根據原作者（發表在 Pixar's RenderMan 官方討論版裏頭）的說詞，有一半是 ptfilter，另一半是 brickmap，我的天…是什麼情況會用到這麼多的 ptfiter，難道是有 100 多顆彈珠散落一地嗎?

最近無聊時，在想一件事。就是呢，為平麼有這麼多的事情都可以被表示成一個樹狀結構（tree）或是圖（graph）呢? 就拿 rendering 這件事來說，一個 RenderMan 的一個 frame，可以被拆成很多個 task，然後每個 task 之間的關係，就組成了像左圖那樣的一個樹狀結構。

然後呢，因為 rendering 真的很費時，至少就 animation 來說是這樣的。（遊戲就當做特例吧，如果一個遊戲的 rendering 要很久的話，會有人想玩嗎?）爭取時間的方法之一就是平行運算（parallel computing）。如果以 task 為最小的運算單元來看，那如何做到同時可以有很多個 task 同時運算，就是重點了。就樹狀結構來看，屬同一層級（sibling）的 task 就可以同時運算，彼此互不相干。

所以呢，這應該就是以樹狀結構來表示一個 job 的好處之一呢?

說來說去，我只是覺得這個 job 的 task 實在太多了，有點噁心，希望我們家的 lighter 不會產生這種 job 來 XD

Glass scene rendered in POV-Ray, demonstrating radiosity, photons, focal blur, and other photorealistic capabilities

當 Opensource 裏頭，有悠久歷史，且常常是學習電腦圖學（Computer Graphics）中的算圖（Rendering）領域的學子，會去拿來當作一個練習平台的 POV-Ray (@Wikipedia)，遇上了工業上赫赫有名的 RenderMan 標準時，就誕生了 POV-Man 這個計畫。

就個人來說，會忍不住想給 POV-Ray 灌上有點神祕，學術上比較高貴的感覺，原因無它，就因為它讓我覺得很遙遠，無從著手，而且除了看到使用它算出來的圖的品質不錯以外，完全不曉得可以拿它來幹麻。

右邊這一張圖，是使用 POV-Ray 算出來的圖，它有 raytracing 特有的反射（reflection）、折射（refraction）和聚焦（caustics，是這樣翻的嗎?）。這張圖同時還算出來景深（Depth of Field）、軟軟的影子（soft shadow，應該不是這樣翻的吧）。